(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
22 November 2001 (22,11.2001) 




PCT 



(10) International Publication Number 

WO 01/88761 A2 



(51) International Patent Classification 7 : G06F 17/30 

(21) International Application Number: PCT/USOl/15575 

(22) International Filing Date: 15 May 2001 (15.05.2001) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

09/571,053 



15 May 2000 (15.05.2000) US 



(71) Applicant (for all designated States except US): INNOVA- 
TIVE COMMUNICATIONS TECHNOLOGIES, INC. 

[US/US]; 9021 Gaither Road, Gaithersburg, MD 20877 
(US). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): MCCONNELL, 
Danny, Edward [US/US]; 7506 Box Elder Court, 
. . McLean, VI 22102 (US). JACOBSON, Jeffrey, Richard 
[US/US]; 7825 Aberdeen Road, Bethesda, MD 20814 
(US). 



(74) Agents: DARBY, George, E. et al.; P.O. Box 10107, 
Greenville, SC 29603 (US). 

(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 
CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH, 
GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, 
LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, 
MX, MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, 
SL, TJ, TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, 
ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, Fl, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 

Declarations under Rule 4.17: 

— as to applicant 's entitlement to apply for and be granted a 
patent (Rule 4.17(H)) for all designations 

[Continued on next page] 



(54) Title: A SYSTEM AND METHOD FOR A PASSIVE INTERNET CACHE 

Paaalve Internet Cache with Socket Matching and PIC Webcacha 
• , tn 6"d-Ueer Node (Flrat Embodiment) 




PtC Primary 
• ncwulata 



hi I — sasag r*i i 



*' - ""V I Hotter 



J 



< 



00 




(57) Abstract: The Passive Internet Cache ("PIC") system builds a global cache at or near end-user nodes, and substantially avoids 
response delays at end-user nodes arising from the exchange of request and response messages between a remote terminal and a 
hub node in a star topology network. Specifically, the PIC system "passively listens" using a secondary monitor (204) to all HTTP 
responses in an outbound channel (216) and enables end-user nodes interfaced with remote terminals (209) to use the contents of 
all HTTP responses in an outbound channel (216), reduces the repetitive transmission of the same HTTP response payloads over 
an outbound channel (216), and in dual channel networks also reduces the need to send HTTP requests over an inbound channel 
(214). The PIC system operates in any star topology network, including without limitation VSAT systems, Direct-to-Home satellite 
systems, and multichannel multipoint distribution service. 
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TITLE OF THE INVENTION 

A SYSTEM AND METHOD FOR A PASSIVE INTERNET CACHE 
BACKGROUND OF THE INVENTION 
1. Field of the Invention 

The Passive Internet Cache system pertains to data caches in "star topology", dual 
channel (send and receive), and single channel (receive only, or "broadcast"), networks that 
use the Hypertext Transfer Protocol ("HTTP"). HTTP is very commonly used with 
Transmission Control Protocol/Internet Protocol ("TCP/IP") over the Internet or private 
networks that have a client/server architecture in which client software operated by an end 
user requests and receives information from one or more server computers. The structure 
of such requests and responses conforms with the specifications for HTTP. HTTP 
specifications are currently promulgated by the World Wide Web Consortium, Cambridge, 
Massachusetts. 

An "HTTP request" from a World Wide Web browser, or other software 
application that uses HTTP messages, to a server computer contains a Uniform Resource 
Locator ("URL") to identify the requested information. The data contents at the address 
specified by a URL can be a complete Webpage, or components of a Webpage (text, 
graphics, sound, video, or other type of file). The "HTTP response" from the server to the 
browser contains the "contents" of the URL, but normally does not restate the URL. The 
cache that is included with commonly available Web browsers interoperates with the 
browser as follows: (a) an end-user clicks on a URL displayed in a browser or other 
window of the display of an electronic device, usually a computer, connected to the 
Internet; (b) the browser acts in conformity with the cache configuration settings of the 
browser, e.g., if the URL is stored in the built-in browser cache, the cache provides the 
contents of the stored URL to the browser unless required by the configuration settings to 
verify that the cached URL has not changed; if verification is required, or if the URL is not 
stored in browser cache, the cache sends an HTTP request message (usually including a 
"GET', or "GET IF-MODIFIED-SINCE" command) to request the URL from the host 
computer specified in the URL; (c) if the disk space used by browser cache exceeds a user- 
defined size, the cache deletes the oldest URLs in cache to accommodate the newest URLs 
and their contents; and (d) upon receipt of the HTTP response to the HTTP request, the 
cache provides the response to the browser and stores the contents of the HTTP response 
in browser cache under the URL specified in the matching HTTP request. The IP packet 
of an HTTP request includes, among other things, a GET (or other permitted) command, 
the requested URL, the IP address and TCP port number (collectively called the "source 
socket") of the end-user's computer, and the destination IP address and TCP port number 
(collectively called the "destination socket") of the Webserver on which the URL resides. 
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The source socket of the HTTP request becomes the destination socket of the HTTP 
response, and the destination socket of the HTTP request becomes the source socket of the 
HTTP response. 

An HTTP request causes the Webserver identified in the request message (i.e., the 

5 host computer at the domain name specified in the URL in the HTTP request) to send a 
Webpage (or Webpage component) identified by the file component of the URL to the 
requesting browser. The Webpage (or Webpage component) sent by the identified 
Webserver is the payload of the HTTP response message. "Browser" in this document 
means any end-user application software that uses HTTP. "HTTP" includes any equivalent 

10 or successor protocol to HTTP that performs "applications and services" functions at OSI 
layers 5 to 7 substantially similar to those of HTTP. "TCP/IP" includes any equivalent or 
successor protocol to TCP/IP that uses methods of message addressing, routing, transport, 
and headers that are substantially similar to those of TCP/IP. 

In normal operation, a Web browser (or other software application that uses HTTP) 

15 only receives the contents of TCP/IP packets that contain (a) the destination IP address of 
the electronic device on which the browser is running, and (b) a TCP port number assigned 
to the Web browser application for the duration of the TCP connection by the operating 
system of the electronic device (or by other software controlling the allocation of TCP 
ports on the device). "Electronic device" or "end-user node" means herein any type of 

20 computational device (a) under the control of an operating system, such as a personal 
computer ("PC"), set-top box, or Internet appliance, and (b) that is interfaced with a dual 
channel or single channel network. An end-user node can be used by a human operator or 
be an unmanned processing node in a computer network. "End-user" means herein the 
client application (typically a browser) that originates HTTP requests and is the final 

25 recipient of HTTP responses. The most common network interfaces are network interface 
cards and dial-up networking adapters. In normal operation, a Web browser opens a TCP 
port, sends an HTTP request on that TCP port, and waits for an HTTP response on that 
TCP port More accurately, the browser (or other client application software) requests that 
the operating system assign to the browser (or other client application software) an unused, 

30 unreserved TCP port number. The browser then uses that TCP port for a communications 
session. When the browser no longer needs the TCP port, the browser relinquishes the 
TCP port number (and therefore the TCP port the TCP port number identifies) back to the 
operating system, and the TCP port number can be reassigned to another application. 
Approximately sixty-four thousand TCP ports are available, which enables a browser to 

35 obtain multiple, concurrent TCP ports and to conduct multiple, concurrent HTTP sessions. 
Typically, the operating system assigns TCP port numbers in an ascending, sequential 
manner. When a TCP session is closed and the TCP port is released back to the operating 
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system, the same port number will normally not be used again until the operating system 
has cycled through the remaining (approximately 64,000) TCP ports. If the IP destination 
address of a packet available to a network interface of an electronic device does not match 
the (or an) IP address of the network interface, the network interface normally ignores or 
5 discards the packet If the IP destination address does match the (or an) IP address of such 
network interface, the TCP/IP stack running in the electronic device forwards the contents 
of the packet to the application (e.g., browser) that opened the TCP port identified in the 
TCP packet header. If the specified TCP port is not open, the packet is ignored or 
discarded. 

10 A traditional standalone cache (not part of a Web browser) matches an HTTP 

request with the HTTP response generated as a reply to the HTTP request, and stores the 
contents of the HTTP response under the URL specified in the HTTP request The 
traditional standalone cache design requires collocation of the cache at a network access 
point where the cache can monitor and buffer traffic as required to provide the caching 

15 function. Being located at such a network access point permits a cache to monitor, copy 
and respond to HTTP requests and to store or cache HTTP responses that transit the access 
point The caching device causes each HTTP request and each HTTP response to be stored 
in buffer memory and/or on a disk drive or other storage. When the URL is stored in the 
cache, the caching device accesses the buffered or cached information and responds to an 

20 HTTP request with the contents of the requested URL. If a URL is not stored in the cache, 
or when it is necessary to verify that the requested URL has not changed (which depends 
on specific cache configuration settings), the cache opens a TCP/IP connection to the 
designated Webserver (on a separate TCP port managed by the TCP/IP stack serving the 
cache) and returns an appropriate HTTP response to the originator of the HTTP request 

25 after receiving the HTTP response from the Webserver. With traditional caching devices, 
the Webserver receives HTTP requests with IP headers containing the IP address and TCP 
port numbers assigned by the caching device rather than those of the originating device, 
such as an end-user node. 

The term "star topology, dual channel network" as used herein means satellite and 

30 terrestrial network architectures in which a plurality of transmit/receive ("TR") remote 
terminals share a return channel (called the outbound channel) transmitted from a central 
switching, or "hub", node to the remote terminals, and in which each TR remote terminal 
uses a uniquely assigned forward communications channel (called the inbound channel) 
that is transmitted from a TR remote terminal to the hub node and is not shared with (and 

35 is not received by) other remote terminals. Very small aperture terminal ("VSAT") 
satellite networks with transmit/receive ("two-way") remote terminals are an example of 
a star topology, dual channel network. In star topology, dual channel networks other than 
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two-way VS AT, the inbound channel from a TR remote terminal to a hub node serving the 
TR remote terminal can be through a terrestrial network, such as by use of terrestrial 
microwave, copper pair, or fiberoptic media; the outbound channel can also be through a 
terrestrial network, such as in digital cablecast networks. All TR remote terminals can 
5 communicate interactively with a hub node. 

The term "star topology, single channel network" as used herein means satellite and 
terrestrial network architectures in which a plurality of receive-only ("RO") remote 
terminals share a return channel (called the "broadcast" or outbound channel) from a hub 
node, and in which each RO remote terminal lacks any inbound channel, direct or indirect, 

10 from an RO remote terminal to a hub node. VSAT satellite networks with receive-only 
("one-way") remote terminals are a common example of a star topology, single channel 
network. A "star topology" network, without qualification as to channels, means star 
topology network with a population of TR remote terminals, RO remote terminals, or a 
mixed population of TR and RO remote terminals. A "remote terminal" means a device 

15 that uses radio frequency, electrical, photonic, or other communications technologies for 
one-way (RO) or two-way (TR) communications between that device and a hub node. A 
remote terminal can be interfaced with one or more local area networks, or equivalent 
connectivity, shared by end-user nodes and other types of nodes. 

A traditional, standalone cache interfaced with a TR remote terminal in a star 

20 topology, dual channel network can monitor (a) only the locally originated, remote 
terminal-to-hub node, inbound channel, and (b) a hub node-to-remote terminals, outbound 
channel. The locally originated inbound channel contains HTTP requests from end-users 
interfaced with the remote terminal. The outbound channel contains HTTP responses to 
a plurality of remote terminals and the end-users interfaced with such remote terminals. 

25 A TR remote terminal in a star topology, dual channel VSAT network cannot directly 
monitor the inbound channels from other TR remote terminals to the hub node. An RO 
remote terminal in a star topology, single channel (broadcast) network does not have an 
inbound channel; there are no transmissions from the RO remote terminal to a hub node 
and therefore no inbound HTTP requests to monitor. An RO remote terminal also cannot 

30 directly monitor the inbound channels from other TR remote terminals to the hub node. An 
RO remote terminal, however, may be interfaced with a local area network on which local 
HTTP requests are carried; a cache associated with an RO remote terminal can provide 
HTTP responses to local HTTP requests. Assuming a TR or RO remote terminal could 
receive HTTP responses addressed to other remote terminals, except in extremely rare 

35 instances described below, a traditional, standalone cache associated with such remote 
terminal can not determine the URLs of such HTTP responses. 
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2. Description of Related Art 

There are a great variety of caching technologies taught by prior art. Some caching 
methods are optimized for use in computer systems (U.S. Patent No. 5,930,5 15, issued to 
Ducharme, et al.), in Internet service provider operations (U.S. Patent No. 5,991,306, 
5 issued to Burns, et al.), or in satellite broadcasting (U.S. Patent No. 5,987,233, issued to 
Humphrey). The related art generally uses a "store and forward" approach in which files 
or data from a source device (e.g., a Webserver) are replicated on one or more other 
storage devices, or caches. The refresh frequency and selection of files and data is 
operator-defined or based on the actual or predicted frequency with which the files or data 

10 have been, or will be, requested by end users. Cache refresh can be either by the source 
initiating a refresh and "pushing" files and data out to cache storage, or by a destination 
initiating a refresh and "pulling" files and data from the source. Existing caching 
methods can be configured using various rules for refreshing cache contents, for using 
drive space, for blocking specified URLs, etc. Such caches can also be configured for use 

15 as proxy servers, in which case an HTTP request generated by an end-user's browser uses 
a destination TCP port defined for the proxy server rather than using a well-known TCP 
port defined for public Webservers. TCP port 80 is a well-known port used by public 
Webservers for receiving HTTP requests. Caches can be cascaded, in which case each 
cache in series either contains the requested URL and returns the appropriate HTTP 

20 response to the requesting browser, or opens a TCP/IP connection to the next cache in 
series and sends an HTTP request to the next cache for the URL. In a cascaded cache 
architecture, when a cache does not contain a requested URL, the cache generates an HTTP 
request to the next device in series, and upon receipt of the HTTP response (which may 
come from the next or subsequent cascaded caching device, or from the Webserver at the 

25 end of the cascade), forwards the HTTP response to the end-user, or to a previous cache 
in a cascaded series of caches. 

HTTP versions prior to HTTP 1.1 did not provide a field for the URL in the header 
of an HTTP response. The implication of this is that a device that monitors HTTP 
responses will not have access to the URL of the payload of an HTTP response when 

30 earlier versions of HTTP are used. This being the case, the URL and its contents cannot 
be cached when the HTTP request that generated the HTTP response is not available. 
When HTTP version 1 .1 or later is used, the Content Location header (a field reserved in 
an HTTP response for the URL of the payload of the response) is an optional field, and 
Webserver programmers are not required to include the field in the HTTP response. The 

35 use of the Content Location header is extremely rare; even when the Content Location 
header is included, the URL field may be missing or incorrect. When programmers do not 
include this field or the stated URL is missing or incorrect, an HTTP response cannot be 
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matched to the corresponding URL unless the HTTP request is available. 

None of the caching technologies described in the related art addresses the problem 
of a remote terminal in a star topology network not having direct access to the inbound 
channels of other remote terminals, or x>f the omission of URLs in HTTP responses in 
5 outbound channels. Traditional, standalone caching technologies for star topology, dual 
channel networks, such as that described in U.S. Patent No. 5,987,233, issued to 
Humphrey, require that a "global" standalone cache be maintained at one or more hub 
nodes (e.g., the hub earth station of a VS AT network) and that a remote terminal send 
HTTP requests through an inbound channel for all URLs that are not in the built-in 

10 browser cache, or other local cache, on a node interfaced with a remote terminal. The 
purpose of traditional caches, especially those associated with a hub node, is to reduce the 
volume of HTTP requests and HTTP responses transiting the span between the cache and 
the Internet, and therefore reduce the required datarate of (or increase the number of users 
supported over) such span. FIG. 1 depicts the current system of caching in a star topology, 

15 dual channel network. FIG 1 A illustrates message exchange when a URL is in a local 
cache. FIG IB illustrates message exchange when a URL is not in local cache or in a 
traditional hub cache. In addition, the use of a traditional cache at a hub node of a satellite 
network provides a proxy function that "intercepts" end-users' HTTP requests for URLs, 
responds with those URLs cached at the hub node (which avoids Internet propagation 

20 delays), but does nothing to avoid the deterioration of response time due to satellite 
propagation delays between the end-user's node and the hub node. The contents of a 
"global" cache at a hub node reflect the activities of all end-users served by the hub 
node(s). In a multi-hub architecture, a "central" or "master" hub periodically collects the 
cache content from all other hub caches by pulling the contents from the hubs and creating 

25 an aggregate cache. The aggregate cache is then periodically pushed to the other hubs to 
replicate the aggregate cache at all hubs. In this architecture, the hub locations are 
generally terrestrial hubs, e.g. an internet service provider point of presence, with end-users 
supported via terrestrial (usually dial-up) access to the hub node. Locating a global cache 
at a hub node has been necessary because only a hub node provides a network access point 

30 that permits the monitoring of all HTTP requests from, and corresponding HTTP responses 
to, all remote terminals. Such caches generate, or obtain and relay, HTTP responses on 
behalf of client applications running on end-user nodes. Providing global caches at 
intermediate nodes or at end-user nodes in a star topology network has heretofore required 
that the cache contents be actively pushed or pulled from the "master caching center" or 

35 global cache at the hub node(s). An "intermediate node" is a node between the hub node 
and an end-user node in a star topology network. Accordingly, there is a need for a more 
efficient and cost effective method and system of building a global cache at intermediate 
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nodes and at end-user nodes in star topology networks. 

The Passive Internet Cache system overcomes the limitation of having to collocate 
a global cache with the hub node(s) of a star topology network, and the limitation imposed 
by the omission of the URL in HTTP responses. The Passive Internet Cache system uses 
5 an innovative, "passive listening" method to construct a global cache at any intermediate 
node, at a series of cascaded intermediate nodes, or at end-user node in star topology 
networks. The Passive Internet Cache system's provision of an HTTP response from a 
global cache at or very near an end-user node means higher cache "hif ' rates for the end- 
user, faster response times, and a corresponding reduction in the use of inbound and 

1 0 outbound communication channels. 

SUMMARY OF THE INVENTION 
The Passive Internet Cache ("PIC") system meets the need for a more efficient and 
cost effective global cache in intermediate nodes or end-user nodes in star topology 
networks. The PIC system builds a global cache at or near end-user nodes, and 

1 5 substantially avoids response delays at end-user nodes arising from the exchange of request 
and response messages between a remote terminal and a hub node. Specifically, the PIC 
system operates in the background and enables end-user nodes interfaced with remote 
terminals to vise the contents of all HTTP responses in an outbound channel, reduces the 
repetitive transmission of the same HTTP response payloads over an outbound channel, 

20 and in dual channel networks also reduces the need to send HTTP requests over an inbound 
channel. The PIC system can be used and is effective in any type of star topology network. 
Suitable dual channel networks include VSAT systems with inbound and outbound 
channels by satellite, or with outbound channel by satellite and inbound channel by 
terrestrial network; Direct-to-Home ("DTH") satellite systems that have a broadcast 

25 outbound satellite channel and a terrestrial inbound channel (dial-up, leased line, cable 
modem, etc.); and terrestrial systems such as multichannel multipoint distribution service 
("MMDS"), local multipoint distribution service ( CC LMDS"), instructional television fixed 
service ("ITFS"), digital television broadcasting, and digital cablecasting systems that have 
a terrestrial "broadcast" or "multicasf * outbound channel and various types of inbound 

30 channels. "Broadcast" means a single message in the outbound channel can be addressed 
to and received by all remote terminals. "Multicast" means a single message in the 
outbound channel can be addressed to and received by a portion of, but not all, remote 
terminals. In addition to star topology, dual channel networks, the PIC system is effective 
in networks with single channel, receive only terminals, such as receive-only VSAT and 

35 DTH satellite terminals. The PIC system is also effective with MMDS, LMDS, ITFS, 
digital television broadcasting, and digital cablecasting terminals that may have two-way 
(transmit/receive) or one-way (receive only) capabilities, whether wireline and/or wireless . 
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A PIC system can be configured to serve a mixed population of TR remote terminals and 
RO remote terminals, and can be configured to use concurrently wireline outbound 
channels, wireless outbound channels, wireline inbound channels, and/or wireless inbound 
channels. This document assumes that end-users are associated with remote terminals and 
originate HTTP requests, and that Webservers (which may be on a local area network at 
the hub node, or may be accessed through other networks serving the hub node) provide 
HTTP responses to the hub node, and the hub node transmits such HTTP responses in the 
outbound channel to the remote terminals. 

The Passive Internet Cache system has five primary components: a monitoring 
component, an encapsulating component, a buffering component, an unencapsulating 
encapsulating'') component, and a global cache (called a "PIC Webcache"). A primary 
monitoring component and an encapsulation component are implemented at a hub node. 
A buffering component can be implemented at a hub node, intermediate node, and/or end- 
user node. The decapsulating component and the PIC Webcache are implemented at an 
intermediate node or at an end-user node of a star topology network. The decapsulating 
component is interfaced or integral with a buffering component at an intermediate node or 
at an end-user node. An example of an intermediate node is a computer or set-top box 
interfaced with, or integral with, a VSAT, DTH, MMDS, LMDS, ITFS, digital television 
broadcasting, or digital cablecasting remote terminal and also interfaced with one or more 
end-user nodes; the interfaces can be a local area network, a system bus, universal serial 
bus ("USB"), or similar connectivity. The distribution of the components of a PIC system 
defines the various embodiments of the invention. All embodiments of the PIC system 
require that aremote terminal output all HTTP responses received in the outbound channel, 
not just those HTTP responses with IP addresses assigned to intermediate nodes and end- 
user nodes interfaced with such remote terminal, to each instance of a secondary 
monitoring component associated with or interfaced with such remote terminal. Such 
output can be obtained by setting configuration options with some commonly available 
remote terminal or hub node systems. If a remote terminal and hub node system does not 
support reception of HTTP responses for nodes other than those attached to a given remote 
terminal, additional hardware and/or software components, such as a signal splitter and 
separate receiver/decoder, must be added to provide the ability to receive all HTTP 
responses in an outbound channel at a remote terminal. 

One embodiment of the PIC system, in the context of a star topology, dual channel 
VSAT network, implements a primary monitoring component and an encapsulating 
component at a hub earth station, and implements a secondary monitoring component, a 
decapsulating component, a buffering component, and a PIC Webcache on an end-user 
node interfaced with a VSAT remote terminal. On the end-user node, the PIC Webcache 
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is configured as a proxy server cache and the Web browser is configured to use such proxy 
server cache. The primary monitoring component of the PIC system at the hub earth 
station monitors all inbound channels from all the VSAT remote terminals to the hub earth 
station. The primary monitoring component copies all HTTP requests from the monitored 
inbound channels, forwards the HTTP requests to the encapsulating component at the hub 
earth station where the HTTP requests are immediately encapsulated in a User Datagram 
Protocol ("UDP") message. Such UDP messages are then immediately transmitted in the 
outbound channel using a broadcast IP address and UDP port monitored by all remote 
terminals that receive such outbound channel and are interfaced with an end-user node that 
has a PIG Webcache. The secondary monitoring component at the end-user node 
communicates through a network interface on the end-user node with the VSAT remote 
terminal. The secondary monitoring component at the end-user node also communicates 
with the decapsulation component and with the buffering component on the end-user node. 
The secondary monitoring component copies from the VSAT remote terminal to the 
decapsulation component all UDP messages, and to the buffering component all HTTP 
messages, received by the remote terminal, not just those packets with an IP destination 
address of the end-user node. When the secondary monitoring component on the end-user 
node receives a UDP packet containing an encapsulated HTTP request, it provides such 
packet to the decapsulation component. The decapsulation component removes the UDP 
encapsulation ("decapsulation"), and forwards the decapsulated HTTP request to the 
buffering component on the end-user node. The buffering component on the end-user node 
communicates with disk drive(s) or other read/write storage device(s) associated with the 
end user node that are used by the PIC Webcache for storage. The buffering component 
at the end-user node stores the decapsulated HTTP request in buffer memory, and opens 
a file (or database record) tagged with the source socket (source IP address and TCP port 
number) and the destination socket (destination IP address and TCP port number) specified 
in the decapsulated HTTP request. The tagged file (or database record) awaits the arrival 
of the relevant HTTP response to be delivered later by the buffering component 

Upon receipt at the hub earth station of an HTTP response from a Webserver, the 
hub earth station transmits the HTTP response in the outbound channel. If a browser 
running on a end-user node interfaced with a VSAT remote terminal originated the HTTP 
request that generated the HTTP response, the HTTP response is received in the outbound 
channel by that VSAT remote terminal, forwarded to the PIC Webcache in the normal 
manner, and delivered by the PIC Webcache, operating as a proxy server cache, to the 
requesting browser. The secondary monitoring component at the end-user node also 
forwards every HTTP response in the outbound channel to the buffering component 
running on the end-user node. If a browser running on an end-user node interfaced with 
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a VS AT remote terminal did not originate the HTTP request that generated the HTTP 
response, the contents of the HTTP response are not passed to the browser upon receipt 
Rather, the buffering component examines the HTTP response to determine the source and 
destination sockets and stores the contents of the HTTP response in the file (or database 
5 record) previously tagged with those sockets (but with source and destination sockets 
reversed in the HTTP request as compared with the HTTP response). After receiving both 
the HTTP request and the HTTP response, the buffering component at the end-user node 
can match the HTTP request with the correct HTTP response, extract the URL identity 
from the HTTP request, and create a file (or database record) for the URL on the storage 

10 device(s) used by the PIC Webcache as if the browser itself had caused the PIC Webcache 
to cache the URL and its contents, but without displaying the URL contents and without 
issuing an HTTP request. To receive and store the HTTP response, the PIC system does 
not obtain or use a TCP port number allocated by the end-user node or interfere with 
normal browser operation. If the browser requests a PIC-cached URL in the fixture, the 

15 contents of the URL will already be in the PIC Webcache, and will be delivered instantly 
from the PIC Webcache to the browser. 

In summary, the Passive Internet Cache system without buffering at a hub node 
comprises a hub node of a star topology network that receives HTTP requests from one 
or more remote terminals, which hub node is interfaced with at least one external server 

20 computer and transmits UDP datagrams, HTTP requests, and HTTP responses in an 
outbound channel from said hub node of the star topology network, and one or more 
intermediate or end-user nodes of said network that receive said UDP datagrams, HTTP 
requests, and HTTP responses and which one or more intermediate or end-user nodes 
are associated with or interfaced with a means for socket-matching HTTP requests and 

25 HTTP responses and for storing in an end-user accessible cache the contents of a given 
HTTP response under the URL extracted from a correctly matched HTTP request. 

The Passive Internet Cache system with buffering at a hub node comprises a hub 
node of a star topology network that receives HTTP requests from one or more remote 
terminals, which hub node is interfaced with at least one external server computer, has a 

30 first means for socket-matching, and transmits UDP datagrams, HTTP requests, and 
HTTP responses in an outbound channel from said hub node of the star topology 
network, and one or more intermediate or end-user nodes of said network that receive 
said UDP datagrams, HTTP requests, and HTTP responses and which one or more 
intermediate or end-user nodes are associated with or interfaced with a second means 

35 for socket-matching HTTP requests and HTTP responses and for storing in an end-user 
accessible cache the contents of a given HTTP response under the URL extracted from 
a correctly matched HTTP request. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other aspects and features of the Passive Internet Cache system 
will be better understood from the following more detailed description and appended 
claims in conjunction with the drawings, of which: 

FIG. 1 illustrates the current system of caching in a star topology, dual channel 
network. 

FIG 1 A illustrates message exchange when a URL is in a local cache. 

FIG IB illustrates message exchange when a URL is not in local or hub cache. 

FIG. 2 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an end-user node in a star topology, dual channel network (first 
embodiment). 

FIG. 2A illustrates the distribution of PIC components in the first embodiment 
FIG. 2B illustrates passive listening and encapsulation at a hub node. 
FIG. 2C illustrates socket matching. 

FIG. 2D illustrates message exchange using socket matching to store URLs and 
URL contents in a PIC Webcache in the first embodiment. 

FIG. 3 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and with PIC Webcache at an end-user node in a star topology, dual 
channel network (second embodiment). 

FIG. 3 A illustrates the distribution of PIC components in the second embodiment. 

FIG. 4 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an intermediate node in a star topology, dual channel network (third 
embodiment). 

FIG. 4A illustrates the distribution of PIC components in the third embodiment 

FIG. 5 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with secondary buffering and PIC Webcache at an end-user node in a star 
topology, dual channel network (fourth embodiment). 

FIG. 5 A illustrates the distribution of PIC components in the fourth embodiment 

FIG. 6 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node, with secondary buffering at an intermediate node, and with PIC Webcache 
at an end-user node in a star topology, dual channel network (fifth embodiment). 

FIG. 6A illustrates the distribution of PIC components in the fifth embodiment. 

FIG. 7 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with PIC Webcache at an intermediate node in a star topology, dual 
channel network (sixth embodiment). 

FIG. 7 A illustrates the distribution of PIC components in the sixth embodiment. 

FIG. 8 illustrates the Passive Internet Cache embodiment with socket matching and 
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PIC Webcache at an end-user node in a star topology, single channel network (seventh 
embodiment). 

FIG. 8 A illustrates the distribution of PIC components in the seventh embodiment. 

FIG. 9 illustrates the Passive Internet Cache embodiment with socket matching at 
5 an intermediate node and with PIC Webcache at an end-user node in a star topology, single 
channel network (eighth embodiment). 

FIG. 9A illustrates the distribution of PIC components in the eighth embodiment. 

FIG. 10 illustrates the Passive Internet Cache embodiment with socket matching 
and PIC Webcache at an intermediate node in a star topology, single channel network 
10 (ninth embodiment). 

FIG. 1 OA illustrates the distribution of PIC components in the ninth embodiment. 

FIG. 1 1 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache at an end-user node in 
a star topology, single channel network (tenth embodiment). 
15 FIG. 1 1 A illustrates the distribution of PIC components in the tenth embodiment. 

FIG. 12 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node, with secondary buffering at an intermediate node, and with PIC 
Webcache at an end-user node in a star topology, single channel network (eleventh 
embodiment). 

20 FIG. 12A illustrates the distribution of PIC components in the eleventh 

embodiment 

FIG. 13 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache and at an intermediate 
node in a star topology, single channel network (twelfth embodiment). 
25 FIG. 13 A illustrates the distribution of PIC components in the twelfth embodiment. 

FIG. 14 is a block diagram of intermediate node and end-user node functional 
modules in a star topology, dual channel network. 

FIG. 14A is a block diagram of hub node functional modules node in a star 
topology, dual channel network. 
30 FIG. 15 is a block diagram of intermediate node and end-user node functional 

modules in a star topology, single channel network. 

FIG. 15A is a block diagram of hub node functional modules node in a star 
topology, single channel network. 

FIG. 1 6 is a block diagram of a PIC system with content authorization. 
35 FIG. 17 is a block diagram of error correction by a buffering component based on 

continuity of TCP sequence numbers. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Preferred embodiments of the invention will now be described with reference to 
FIGS. 1 to 17. It will be appreciated by those of ordinary skill in the art that the 
description given herein with respect to those figures is for exemplary purposes only and 
5 is not intended in any way to limit the scope of the invention. 

The Passive Internet Cache has five components, some of which may be distributed 
among hub, intermediate, and/or end-user nodes, as described below. The five 
component are: a monitoring component, an encapsulating component, a buffering 
component, an unencapsulating ("decapsulating") component, and a global cache 

10 (called a "PIC Webcache"). A primary monitoring component and an encapsulation 
component are implemented at hub node(s) in all embodiments. A buffering 
component can be implemented at a hub node, intermediate node, and/or end-user node. 
The primary monitoring component at a hub node monitors all IP addresses and TCP 
ports involved in HTTP sessions in use by all nodes using inbound and outbound 

15 channels handled by such hub node, and provides those addresses and ports to the 

various implemented buffering component(s) to enable tracking of all IP addresses and 
TCP ports involved in HTTP sessions; such buffering and tracking enables the 
matching of source sockets and destination sockets used in each of the embodiments. 
The encapsulating component encapsulates HTTP requests in broadcast UDP (or other 

20 connectionless protocol suitable for broadcast or multicast transmission) messages that 
are transmitted from a hub node through an outbound channel and are addressed to all 
remote terminals that can receive that outbound channel A secondary monitoring 
component, a decapsulating component, a buffering component, and a PIC Webcache 
can be implemented at an intermediate node or at an end-user node. The decapsulating 

25 component is interfaced or integral with a buffering component at an intermediate node 
or at an end-user node. An example of an intermediate node is a computer or set-top 
box interfaced with, or integral with, a remote terminal and also interfaced with one or 
more end-user nodes; the interfaces can be a local area network, a system bus, USB, or 
similar connectivity. "Associated with" means two hardware or software devices are 

30 either integral or veiy closely interfaced, as through a system bus, proximate area 
network, USB, high speed local area network, or other close range connectivity, for 
message exchange. "Interfaced with" means two hardware or software devices are 
closer in distance to each other than to the hub node, normally have a higher datarate 
connection between such devices than to the hub node, and are interconnected through 

35 a local area network, or other medium range connectivity, for message exchange. 

"Buffer" or "buffer memory" means random access memory, disk storage, or equivalent 
read/write technology suitable for the short term storage and retrieval of digital 
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information. 

With reference to FIG. 2B, passive listening and encapsulation is implemented at a 
hub node of a dual channel, star topology network by providing a primary monitoring 
component (201) with unlimited, or "promiscuous" access to all HTTP messages 
5 inbound from remote terminals. A hub node in such a star topology network typically 
has a plurality of remote terminals whose inbound channels (each denoted "Rev" in 
FIG. 2B) are received at the hub node, and whose TCP/IP messages are routed to the 
Internet, a private network, and/or a traditional cache. The primary monitoring 
component (201) listens to all inbound HTTP messages in such TCP/IP messages, and 
10 provides HTTP requests to the encapsulation component (202). The encapsulation 
component (202) encapsulates each HTTP request as a broadcast UDP (or other 
connectionless protocol suitable for broadcast or multicast transmission) message and 
provides each such message to the outbound channel of the hub node (denoted as 
"Xmit"inFIG.2B). 

15 The distribution of the components of aPIC system within a star topology network 

defines the various embodiments of the invention. All embodiments of the PIC system 
require that a remote terminal output all HTTP responses received through the outbound 
channel, not just those HTTP responses with IP addresses assigned to intermediate nodes 
and end-user nodes interfaced with such remote terminal, to each instance of a secondary 

20 monitoring component associated with or interfaced with such remote terminal. Such 
output can be obtained by setting configuration options with some commonly available 
remote terminal or hub node systems. In other instances, existing remote terminal and hub 
node systems may not support reception of HTTP responses by a remote terminal other 
than HTTP responses addressed to a specific remote terminal; in these cases, additional 

25 hardware and/or software components must be added to a remote terminal to provide the . 
ability to receive all HTTP responses in an outbound channel. Where such additional 
hardware and software components are required to receive all HTTP responses in an 
outbound channel, a signal splitter (e.g., a RF- or IF-band splitter for wireless outbound 
channels) and separate receiver/decoder installed at a remote terminal is usually sufficient. 

30 The HTTP requests and HTTP responses transmitted through the communications 

paths in a PIC system are not handled through a traditional TCP/IP stack and do not 
involve the use of TCP acknowledgements. The buffering component, whether associated 
with or interfaced with a hub node, an intermediate node, or an end-user node, uses socket- 
matching to pair an HTTP request with the correct HTTP response. With reference to 

35 FIGS. 2 and 2C, in the socket-matching process in a PIC embodiment with buffering and 
PIC Webcache at an end-user node, the buffering component (206) examines the packets 
forwarded by the secondary monitoring component (204). The field sequence observed 
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in HTTP packets is: source IP address (abbreviated "IPs-" in FIG. 2C), destination IP 
address (abbreviated "IPd-" in FIG. 2C), source TCP port number (abbreviated "TCPs-" 
in FIG. 2C), destination TCP port number (abbreviated "TCPd-" in FIG. 2C), and the 
payload (either an HTTP request or an HTTP response). The secondary monitoring 
5 component (204) forwards each HTTP response (the first packet in packet stream 220, in 
FIG 2C) directly to the buffering component (206) and forwards each UDP packet (the 
second packet in packet stream 220, in FIG 2C) to the decapsulation component (205, in 
FIG. 2), which decapsulates any HTTP request contained in such packet and forwards the 
HTTP request so decapsulated to the buffering component (206). When the buffering 

10 component (206) receives an HTTP response, it examines the source and destination 
sockets, and checks to see if a file (or database record) in buffer memory containing an 
HTTP request has been tagged with those source and destination sockets. The source and 
destination sockets are reversed in an HTTP request as compared with the corresponding 
HTTP response. The buffering component compensates for the reversal of source and 

1 5 destination sockets when it compares HTTP requests and HTTP responses. If the buffering 
component can match a received HTTP response with a buffered HTTP request, it extracts 
the URL identity from the HTTP request, and creates a file (or database record) for the 
URL on the storage device(s) (212, in FIG. 2) used by the PIC Webcache (207, in FIG. 2) 
as if the PIC Webcache itself had cached the URL. If the buffering component cannot 

20 match the a received HTTP response with a buffered HTTP request, the buffering 
component creates a file (or database record) tagged with the sockets of the HTTP 
response, and stores such file (or database record) in buffer memory. In the case of packet 
stream (220), the HTTP response with addressing of "IPsb, IPda, TCPsb, TCPda," in the 
first portion of packet stream (220) would be buffered and subsequently matched with the 

25 decapsulated HTTP request with addressing of "IPsa, IPdb, TCPsa, TCPdb," in the second 
portion of packet stream (220). To introduce a second example of socket matching, if the 
buffering component (206) receives the HTTP request in the first packet in packet stream 
(221) that contains source and destination sockets that the buffering component cannot 
match with a previously buffered HTTP response, the buffering component creates a file 

30 (or database record) tagged with the sockets of that HTTP request, and buffers such file (or 
database record). When the buffering component subsequently receives the HTTP 
response in the second portion of packet stream (221), it examines the source and 
destination sockets of that HTTP response, matches those sockets with the previously 
buffered file (or database record) tagged with those source and destination sockets 

35 (compensating for the reversal of source and destination sockets), extracts the URL identity 
from the HTTP request, and creates a file (or database record) for the URL on the storage 
device(s) (212) used by the PIC Webcache (207) as if the PIC Webcache itself had cached 
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the URL. Regardless of whether the HTTP request or the HTTP response is received first, 
to receive and store the URL and the contents of the URL, the PIC system does not obtain 
or use a TCP port number allocated by the end-user node. Thus, even though the browser 
at the end-user node had not previously requested a URL in the PIC Webcache, if the 
5 browser does request that URL in the future, the contents of the URL will already be in the 
PIC Webcache serving the browser, and will be delivered instantly from the PIC Webcache 
to the browser. 

FIG. 2D illustrates the messages exchanged in the operation of a PIC Webcache in 
a PIC embodiment with buffering and PIC Webcache at an end-user node. In FIG. 2D, an 

10 unseen remote terminal transmits an HTTP request that is monitored by the primary 
monitoring component at a hub node and handled as described above and as depicted in 
the upper, leftward message flows in FIG. 2D. That HTTP request is also sent in the 
customary manner from the hub node to a traditional proxy or cache as depicted in the 
upper, rightward message flows in FIG. 2D; if the URL is not found in the traditional 

15 proxy or cache, the HTTP request is forwarded to the Webserver identified in the URL. 
The traditional proxy or cache, or the Webserver, as the case may be, replies to the HTTP 
request with an HTTP response, which the hub node transmits in the outbound channel as 
described above and as depicted in the lower, leftward message flows in FIG. 2D. 
Socket-matching and storage of the URL and its contents is performed at the end-user 

20 node, as described above. 

The buffering component in the first embodiment only proceeds with writing the 
contents of the HTTP response in the PIC Webcache under the URL contained in the 
HTTP request if no errors are detected in the HTTP response and HTTP request. The 
buffering component uses the error detection techniques of TCP, such as confirming a 

25 continuous series of TCP header sequence numbers, to detect errors. If no errors are 
detected, the buffering component writes the contents of the matched HTTP response in 
the PIC Webcache under the URL contained in the matching HTTP request If errors are 
detected in an HTTP request, the request is discarded, and any HTTP responses that have 
not been matched after the expiration of an operator-controlled time period are also 

30 discarded. If errors are detected in an HTTP response, and the intermediate node or end- 
user node has access to an inbound channel, the buffering component can issue an HTTP 
request for a replacement HTTP response. If errors are detected in the HTTP response, and 
the intermediate node or end-user node does not have access to an inbound channel by 
which to issue an HTTP request, the matched but defective HTTP response and matching 

35 HTTP request are discarded. Normally, any single end-user node would only request a 
small portion of the contents of a PIC Webcache within a given time period, so such 
discarding of corrupted or missing HTTP responses and HTTP requests should have an 
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insignificant impact on the overall performance improvements afforded by use of a PIC 
Webcache. 

The embodiments of the PIC system fall into two categories: embodiments for dual 
channel, star topology networks, and embodiments for single channel, star topology 
networks. With each category, there are two sub-categories of embodiments: 
embodiments that perform initial socket-matching at a hub node, and embodiments that 
that do not perform any socket-matching at a hub node. FIGS. 14 and 14A are block 
diagrams of intermediate node, end-user node, and hub node functional modules in a star 
topology, dual channel network. FIGS. 15 and 15A are block diagrams of intermediate 
node, end-user node, and hub node functional modules in a star topology, single channel 
network. Within each sub-category, there are three basic embodiments that are 
distinguished by whether a buffering component is implemented at an intermediate node 
or at an end-user node, and by whether a PIC Webcache is implemented at an intermediate 
node or at an end-user node, as illustrated in FIGS. 14 and 15 for dual channel and single 
channel networks, respectively. 

First Embodiment : Buffering and PIC Webcache at end-user node (TR: Socket Matching 
at End-User Node ("EUN")) 

FIG. 2 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an end-user node in a star topology, dual channel network. FIG. 2A 
illustrates the distribution of PIC components in the first embodiment. FIG. 2B illustrates 
passive listening and encapsulation. FIG. 2C illustrates socket matching. FIG. 2D 
illustrates message exchange using socket matching to store URLs and URL contents in 
a PIC Webcache in the first embodiment. Reference numerals for the first embodiment are 
to Fig. 2 unless otherwise noted. 

A first embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (20 1 ) and an encapsulation 
component (202) at a hub node (203 in Fig. 2A), and a secondary monitoring component 
(204), a decapsulation component (205), a buffering component (206), and a PIC 
Webcache (207) at an end-user node (208 in Fig. 2A) interfaced with a remote terminal 
(209). In the context of a star topology, dual channel network, this embodiment of the 
Passive Internet Cache system provides the lowest cost end-user node for a PIC system. 
Assuming a remote terminal can output all HTTP responses by the use of configuration 
settings, the typical PIC components at the end-user node are software modules installed 
on an end-user PC and, as such, require no hardware investment to implement The PIC 
Webcache is configured as a proxy server cache and the Web browser on the end-user node 
is configured to use such proxy server cache. The primary monitoring component (201) 
at the hub node (203) monitors all inbound channels transmitted from all the remote 
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terminals (209, 213) to the hub node (203). The primary monitoring component (201) 
copies all HTTP requests from the monitored inbound channels (214, 215), provides each 
HTTP request to the encapsulating component (202), and the encapsulating component 
(202) immediately encapsulates each copied HTTP request in a UDP (or other 
5 connectionless protocol suitable for broadcast or multicast transmission) message. The 
encapsulating component provides each UDP message to the outbound channel (216) for 
transmission in the outbound channel using a broadcast IP address and UDP port (or other 
suitable protocol, address, and port) monitored by all remote terminals that receive such 
outbound channel and are interfaced with PIC components on end-user nodes. The 

10 secondary monitoring component (204) on the end-user node (208) communicates through 
a network interface on the end-user node with the remote terminal (209). Using a first 
communications path (210) on the end-user node (208), the secondary monitoring 
component (204) also communicates with the decapsulation component (205), and the 
decapsulation component (205) communicates with the buffering component (206). The 

15 secondary monitoring component (204) copies all of the encapsulated UDP packets from 
the remote terminal (209) to the decapsulation component (205) through a first portion of 
the first communications path (210). When the secondary monitoring component (204) 
on the end-user node provides a UDP packet containing an encapsulated HTTP request to 
the decapsulation component (205), the decapsulation component (205) removes the UDP 

20 encapsulation ("decapsulation"), and forwards each decapsulated HTTP request to the 
buffering component (206) at the end-user node (208 in FIG. 2 A) through a second portion 
of the first communications path (210). The buffering component (206) at the end-user 
node communicates with disk drive(s) (212) or other read/write storage device(s) 
associated with the end user node that are used by the PIC Webcache (207) for storage. 

25 The buffering component (206) stores the decapsulated HTTP request in buffer memory, 
and opens a file (or database record) tagged with the source socket (source IP address and 
TCP port number) and the destination socket (destination IP address and TCP port number) 
specified in the decapsulated HTTP request. The tagged file (or database record) would 
normally be on the storage device(s) used by the PIC Webcache. The tagged file (or 

30 database record) awaits the arrival of the contents of the relevant HTTP response to be 
delivered later from the buffering component. 

Upon receipt at the hub node of an HTTP response, the hub node (203 in FIG. 
2A) transmits the HTTP response in the outbound broadcast channel (216 in FIG. 2). If 
a browser running on a end-user node interfaced with a remote terminal originated the 

35 HTTP request that generated the HTTP response, the HTTP response is received in the 
outbound channel by that remote terminal, forwarded to the PIC Webcache in the 
normal manner, and delivered by the PIC Webcache, operating as a proxy server cache, 

18 



WO 01/88761 



PCT7US01/15575 



to the requesting browser. The secondary monitoring component (204) forwards 
through a second communications path (21 1) to the buffering component on the end- 
user node all HTTP packets received by the remote terminal (209), not just those 
packets with an IP destination address of the end-user node (208). If a browser running 
on an end-user node interfaced with a remote terminal did not originate the HTTP 
request that generated the HTTP response, the contents of the HTTP response are not 
passed to the browser upon receipt. Rather, the buffering component on the end-user 
node examines the HTTP response to determine the source and destination sockets and 
stores the contents of the HTTP response in the file (or database record) previously 
tagged with those sockets (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response). After receiving both the HTTP request 
and the HTTP response, the buffering component at the end-user node can match the 
HTTP request with the correct HTTP response, extract the URL identity from the 
HTTP request, and create a file (or database record) for the URL on the storage 
device(s) (212) used by the PIC Webcache as if the PIC Webcache itself had cached the 
URL. To receive and store the HTTP response, the PIC system does not obtain or use a 
TCP port number allocated by the end-user node. If the browser requests that URL in 
the future, the contents of the URL will already be in the PIC Webcache serving the 
browser, and will be delivered instantly from the PIC Webcache to the browser. 

In the event the browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated an HTTP response provided by 
the monitoring component at the end-user node to the buffering component at the end-user 
node, and the buffering component at the end-user node has not yet received, via a UDP 
message from the hub node, a copy of the HTTP request that triggered such HTTP 
response, the buffering component at the end-user node stores the HTTP response in buffer 
memory, tagged by source socket and destinationsocket, until the associated HTTP request 
arrives via a UDP message from the hub node. Upon receipt and decapsulation of the 
HTTP request, the buffering component can match the HTTP request with the correct 
HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) used by the PIC Webcache as if the 
PIC Webcache itself had cached the URL and its contents. 

Second Embodiment: Buffering at intermediate node and PIC Webcache at end-user node 
(TR: Socket Matching at intermediate node ("IN")) 

FIG. 3 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and with PIC Webcache at an end-user node in a star topology, dual 
channel network. FIG. 3 A illustrates the distribution of PIC components in the second 
embodiment. Reference numerals are to FIG. 3 unless otherwise noted. 
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A second embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a buffering component (306) at an intermediate node (3 1 7 in 
FIGS. 3 and 3 A) and a PIC Webcache (307) at an end-user node (308 in FIGS. 3 and 3 A. 
The second embodiment has the advantage of requiring only one instance of a buffering 
component interfaced with a given remote terminal; the buffering component serves all 
end-user nodes on one or more local area networks (or other local connectivity) served by 
that remote terminal. This embodiment provides fast end-user response times through the 
use of PIC Webcaches at end-user nodes. Additionally, the use of a separate processor for 
the monitoring and buffering components at an intermediate node permits higher 
performance memory and a dedicated processor or processors to handle these functions, 
off-loading those processing requirements from the end-user nodes. TCP/IP is used in the 
local area network (or other connectivity) between the buffering component at the 
intermediate node and the PIC Webcache in end-user nodes. 

The second embodiment of the Passive Internet Cache system implements a 
primary monitoring component (30 1 ) and an encapsulation component (3 02) at a hub node, 
a secondary monitoring component (304) , a decapsulation component (305), and a 
buffering component (306) at a computer or set-top box that is interfaced with, or is an 
integral part of, a remote terminal (309) and is also interfaced with a local area network 
(318) (or other connectivity) that serves one or more end-user nodes, and the PIC 
Webcache (307) component at one or more end-user nodes (308). The end-user nodes may 
also communicate directly with a remote terminal for communications unrelated to the PIC 
system. The PIC Webcache in this embodiment is configured as a proxy server cache and 
the Web browser on the end-user node is configured to use such proxy server cache. The 
primary monitoring component (301) and the encapsulation component (302) of the PIC 
system at the hub node (303) function as described above. The secondary monitoring 
component (304) at the intermediate node communicates through a network, internal bus 
or other interface with the remote terminal. The secondary monitoring component (304) 
also communicates with the decapsulation component (305), and with the buffering 
component (306), at the intermediate node. The secondary monitoring component (304) 
copies from the remote terminal (309) to the decapsulation component (305) on the 
intermediate node all encapsulated UDP packets, and to the buffering component (306) on 
the intermediate node, all HTTP packets, received by the remote terminal, not just those 
packets with an IP destination address of the intermediate node or of end-user nodes served 
by that remote terminal. When the secondary monitoring component (304) receives a 
UDP packet containing an encapsulated HTTP request, it provides such packet through a 
first portion of a first communications path (310) to the decapsulation component (305) at 
the intermediate node. The decapsulation component (305) decapsulates the HTTP 
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request, and forwards eachdecapsulated HTTP request through a second portion of the first 
communications path (310) to the buffering component (306) at the intermediate node. 
The buffering component (306) at the intermediate node communicates with disk drive(s) 
or other read/write storage device(s) (3 12) associated with each end user node that are used 
5 by one or more end-user nodes' PIC Webcaches (307) for storage. The buffering 
component at the intermediate node stores the decapsulated HTTP request in buffer 
memory, and opens a file (or database record) tagged with the source socket (source IP 
address and TCP port number) and the destination socket (destination IP address and TCP 
port number) specified in the decapsulated HTTP request. The tagged file (or database 

10 record) would normally be on the storage device(s) used by each PIC Webcache interfaced 
with the intermediate node. The tagged file awaits the arrival of the contents of the 
relevant HTTP response to be delivered later by the buffering component 

Upon receipt at the hub node of an HTTP response, the hub node (303 in FIG 3 A) 
transmits the HTTP response in the outbound broadcast channel (316 in FIG. 3). If a 

1 5 browser running on a end-user node interfaced with a remote terminal originated the HTTP 
request that generated the HTTP response, the HTTP response is received in the outbound 
channel by that remote terminal, forwarded to the PIC Webcache in the normal manner, 
and delivered by the PIC Webcache, operating as a proxy server cache, to the requesting 
browser. The secondary monitoring component at the intermediate node forwards through 

20 a second communications path (3 1 1) every HTTP response in the outbound channel to the 
buffering component running on the intermediate node. If a browser running on an end- 
user node interfaced with a remote terminal did not originate the HTTP request that 
generated the HTTP response, the contents of the HTTP response are not passed to the 
browser upon receipt. Rather, the buffering component on the intermediate node examines 

25 the HTTP response to determine the source and destination sockets and stores the contents 
of the HTTP response in the file (or database record) previously tagged with those sockets 
(the source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response). After receiving both the HTTP request and the HTTP response, the 
buffering component at the intermediate node can match the HTTP request with the correct 

30 HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) used by each PIC Webcache as if 
each PIC Webcache itself had cached the URL. To receive and store the HTTP response, 
the PIC system typically uses a local area network (3 1 8) and may use TCP port numbers 
allocated by end-user nodes interfaced with the intermediate node for the purpose of 

35 directly accessing and updating the PIC Webcache on the disk(s) of the end-user PCs. If 
the browser requests that URL in the future, the contents of the URL will already be in the 
PIC Webcache serving the browser, and will be delivered instantly from the PIC Webcache 
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to the browser. 

In the event the browser running on an end-user node interfaced with an 
intermediate PIC component on a remote terminal did not originate the HTTP request that 
generated an HTTP response provided by the secondary monitoring component at the 

5 intermediate node to the buffering component at the intermediate node, and the buffering 
component at the intermediate node has not yet received via an encapsulated UDP message 
from the hub node containing a copy of the HTTP request that triggered such HTTP 
response, the buffering component at the intermediate node stores the HTTP response in 
buffer memory, tagged by source socket and destination socket, until the correct 

10 (matchable sockets) HTTP request arrives via an encapsulated UDP message from the hub 
node. Upon receipt and decapsulation of the HTTP request, the buffering component can 
match the HTTP request with the correct HTTP response, extract the URL identity from 
the HTTP request, and create a file (or database record) for the .URL on the storage 
device(s) used by a PIC Webcache as if the PIC Webcache itself had cached the URL and 

15 its contents. 

Third Embodiment : Buffering and PIC Webcache at intermediate node (TR: Socket 
Matching at IN) 

FIG. 4 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an intermediate node in a star topology, dual channel network. FIG. 4A 

20 illustrates the distribution of PIC components in the third embodiment. Reference 
numerals are to FIG. 4 unless otherwise noted. 

A third embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a buffering component (406) and a PIC Webcache (407) an 
intermediate node (417). This embodiment has the advantage of requiring only one 

25 instance of the secondary monitoring component, buffering component, and PIC Webcache 
to serve all end-user nodes on one or more local area networks (418) (or other local 
connectivity) interfaced with the intermediate node, and providing improved response time 
without the expense of have end-user nodes equipped with caching devices. Additionally, 
high performance memory, storage, and dedicated processor(s) can provide performance 

30 improvements by off-loading processing and storage requirements from the end-user 
nodes. Such a configuration is well-suited to a residential set-top box used as an 
intermediate node, with home PCs, appliances, security, and environmental systems as 
end-user nodes. TCP/IP is used in the local area network (or other connectivity) between 
the intermediate node and the end-user nodes. 

35 The third embodiment of the Passive Internet Cache system implements a primary 

monitoring (401) and an encapsulation component (402) at a hub node, a secondary 
monitoring component (404), decapsulation component (405), buffering component (406), 
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and PIC Webcache (407) at a comptrter or set-top box that is interfaced with, or is an 
integral part of, a remote terminal (409) and is also interfaced with a local area network 
(418) (or other connectivity) that serves one or more end-user nodes. The end-user nodes 
may also communicate directly with a remote terminal for communications unrelated to 
5 the PIC system. The PIC Webcache in this embodiment may be configured as a proxy 
server cache (i.e., browsers configured to use a TCP port for HTTP that is uniquely 
allocated to the PIC Webcache) or as a caching appliance (i.e., browsers need not be 
configured to use a TCP port for HTTP that is uniquely allocated to the PIC Webcache, 
and would normally use well-known TCP port 80). The Web browser on the end-user 

10 node must be configured for proxy server cache if the proxy configuration is implemented. 
If the PIC Webcache is configured as a caching appliance, it is not necessary to configure 
browsers on end-user nodes to use a caching appliance, since using well-known TCP port 
80 in the destination socket directs HTTP requests through the caching appliance. The 
primary monitoring component (401) and the encapsulation component (402) of the PIC 

15 system at the hub node function (403 in FIG. 4A) as described for the first and second 
embodiments. In addition, the secondary monitoring component (404), and the 
decapsulation component (405), at the intermediate node communicate and function as 
described in the second embodiment. The buffering component (406) at the intermediate 
node communicates with disk drive(s) (412) or other read/write storage device(s) 

20 associated with the intermediate node that are used by one or more PIC Webcaches (407) 
at the intermediate node for storage. The buffering component at the intermediate node 
stores the decapsulated HTTP request in buffer memory, and opens a file (or database 
record) tagged with the source socket (source IP address and TCP port number) and the 
destination socket (destination IP address and TCP port number) specified in the 

25 decapsulated HTTP request. Multiple PIC Webcaches may be associated with the 
intermediate node to enable load-sharing or redundancy. The tagged file (or database 
record) would normally be on the storage device(s) used by the PIC Webcache at the 
intermediate node. The tagged file (or database record) awaits the arrival of the contents 
of the relevant HTTP response to be delivered later by the buffering component. 

30 Upon receipt at the hub node of an HTTP response, the hub node (403 in FIG 4 A) 

transmits the HTTP response in the outbound broadcast channel (416 in FIG. 4). If a 
browser running on a end-user node interfaced through a PIC-equipped intermediate node 
to a remote terminal originated the HTTP request that generated the HTTP response, the 
HTTP response is received in the outbound channel by that remote terminal, forwarded to 

35 the PIC Webcache in the normal manner, and delivered by the PIC Webcache, operating 
either as a proxy server cache or as a caching appliance, to the requesting browser. The 
secondary monitoring component at the intermediate node forwards through a second 
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communications path (411) every HTTP response in the outbound channel to the buffering 
component running on the intermediate node. If a browser running on an end-user node 
interfaced through a PIC-equipped intermediate node to a remote terminal did not originate 
the HTTP request that generated the HTTP response, the contents of the HTTP response 
are not passed to the browser upon receipt. Rather, the buffering component on the 
intermediate node examines the HTTP response to determine the source and destination 
sockets and stores the contents of the HTTP response in the file (or database record) 
previously tagged with those sockets (the source and destination sockets are reversed in 
the HTTP request as compared with the HTTP response). After receiving both the HTTP 
request and the HTTP response, the buffering component at the intermediate node can 
match the HTTP request with the correct HTTP response, extract the URL identity from 
the HTTP request, and create a file (or database record) for the URL on the storage 
device(s) used by the PIC Webcache(s) at the intermediate node as if the relevant PIC 
Webcache itself had cached the URL. To receive and store the HTTP response, the PIC 
system does not obtain or use a TCP port number allocated by end-user nodes interfaced 
with the intermediate node. If a browser on an end-user node requests that URL in the 
future, the contents of the URL will already be in the PIC Webcache, and will be delivered 
from the PIC Webcache to the browser. 

In the event the browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated an HTTP response provided by 
the secondary monitoring component at the intermediate node to the buffering component 
at the intermediate node, and the buffering component at the intermediate node has not yet 
received, via an encapsulated UDP message from the hub node, a copy of the HTTP 
request that triggered such HTTP response, the buffering component at the intermediate 
node stores the HTTP response in buffer memory, tagged by source socket and destination 
socket, until the correct (matchable sockets) HTTP request arrives via an encapsulated 
UDP message from the hub node. Upon receipt and decapsulation of the HTTP request, 
the buffering component can match the HTTP request with the correct HTTP response, 
extract the URL identity from the HTTP request, and create a file (or database record) for 
the URL on the storage device(s) used by the PIC Webcache(s) on the intermediate node 
as if the relevant PIC Webcache itself had cached the URL and its contents. 
Fourth Embodiment: Split Buffering (hub and end-user nodes) and PIC Webcache at end- 
user node (TR: Socket Matching at hub node ("HN")) 

FIG. 5 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with secondary buffering and PIC Webcache at an end-user node in a star 
topology, dual channel network, FIG. 5 A illustrates the distribution of PIC components 
in the fourth embodiment Reference numerals are to FIG. 5 unless otherwise noted. 
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A fourth embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (501), an encapsulation 
component (5 02), and a primary buffering component (5 1 9) at a hub node, an initial socket 
matching function in the primary buffering component (519) at the hub node, and a 
secondary monitoring component (504), a secondary buffering component (506), a 
decapsulation component (505), and a PIC Webcache (507) at an end-user node (508 in 
FIG. 5A). In the context of a star topology, dual channel network with a large number of 
remote terminals, the use of a primary buffering component at the hub node permits a 
smaller buffer memory, lower performance storage, and a lower performance processor to 
be used by the secondary buffering component at the end-user node. Assuming a remote 
terminal can output all HTTP responses by the use of configuration settings, the typical 
PIC components at the end user node are software modules installed on an end-user PC 
and, as such, require no hardware investment to implement The PIC Webcache is 
configured as a proxy server cache and the Web browser on the end-user computer is 
configured to use such proxy server cache. The primary monitoring component (501) at 
the hub node monitors all inbound channels transmitted from all the remote terminals (509, 
5 1 3) to the hub node . The primary monitoring component (501) copies all HTTP requests 
from the monitored inbound channels (5 14, 5 1 5), and forwards each HTTP request to the 
encapsulation component (502). The encapsulation component creates a UDP packet 
containing the HTTP request using a broadcast IP address and port as described above, and 
forwards the encapsulated packet to the primary buffering component (519) at the hub 
node. The primary buffering component (519) stores the encapsulated HTTP request in 
buffer memory, tagged with the source socket (source IP address and TCP port number) 
and the destination socket (destination IP address and TCP port number) specified in the 
HTTP request The primary buffering component at the hub node examines the source and 
destination sockets in the IP packet containing the HTTP response and matches them with 
the destination and source sockets in the appropriate previously UDP-encapsulated IP 
packet containing the HTTP request. Upon receipt at the hub node of an HTTP response, 
the primary monitoring component (501) provides the HTTP response to the primary 
buffering component (519) at the hub node. The HTTP response is not immediately 
broadcast by the hub node in the outbound channel. The primary buffering component 
(519) at the hub node examines the source and destination sockets in the IP packet 
containing the HTTP response and matches them with the destination and source sockets 
in the corresponding, previously UDP-encapsulated IP packet containing the HTTP request 
(the source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response). The primary buffering component (519), soon after providing the 
encapsulated HTTP request to the outbound channel (516), provides the corresponding 



25 



WO 01/88761 



PCT/US01/15575 



HTTP response to tbe outbound channel (516) for transmission to the remote terminals 
(509, 513). 

The secondary monitoring component (504) at the end-user node (508, in FIG. 5 A) 
communicates through a network interface on the end-user node with the remote terminal 

(509) . The secondary monitoring component (504) also communicates through a first 
communications path (5 1 0) with the decapsulation component (505), and thence with the 
secondary buffering component (506), at the end-user node. The secondary monitoring 
component (504) copies from the remote terminal through the first communications path 

(510) to the decapsulation component (505) on the end-user node all encapsulated UDP 
packets, and through a second communications path (511) to the secondary buffering 
component on the end-user node all HTTP packets, received by the remote terminal, not 
just those packets with an IP destination address of the end-user node. When the 
secondary monitoring component (504) on the end-user node receives a UDP packet 
containing an encapsulated HTTP request, it provides through a first portion of the first 
communications path (510) such packet to the decapsulation component. The 
decapsulation component removes the UDP encapsulation ("decapsulation"), and forwards 
through a second portion of the first communications path (510) each decapsulated HTTP 
request to the buffering component at the end-user node. The buffering component at the 
end-user node communicates with disk drive(s) or other read/write storage device(s) 
associated with the end user node that are used by the PIC Webcache for storage. The 
buffering component stores the decapsulated HTTP request in buffer memory, and opens 
a file (or database record) tagged with the source socket (source IP address and TCP port 
number) and the destination socket (destination IP address and TCP port number) specified 
in the decapsulated HTTP request. The tagged file (or database record) would normally 
be on the storage device(s) used by the PIC Webcache. The tagged file (or database 
record) awaits the arrival of the contents of the relevant HTTP response from the buffering 
component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to the PIC Webcache 
in the normal manner, and delivered by the PIC Webcache, operating as a proxy server 
cache, to the requesting browser. The secondary monitoring component (504) at the end- 
user node also forwards through the second communications path (511) every HTTP 
response in the outbound channel to the secondary buffering component (506) running on 
the end-user node. If a browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated the HTTP response, the 
contents of the HTTP response are not passed to the browser upon receipt Rather, the 
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secondary buffering component on the end-user node examines the HTTP response to 
determine the source and destination sockets and stores the contents of the HTTP response 
in the file (or database record) previously tagged with those sockets (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 

5 response). After receiving both the HTTP request and the HTTP response, the secondary 
buffering component at the end-user node can match the HTTP request with the correct 
HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) (512) used by the PIC Webcache 
(507) as if the PIC Webcache itself had cached the URL. To receive and store the HTTP 

10 response, the PIC system does not obtain or use a TCP port number allocated by the end- 
user node. If the browser requests that URL in the future, the contents of the URL will 
already be in the PIC Webcache serving the browser, and will be delivered instantly from 
the PIC Webcache to the browser. 

Fifth Embodiment : Split Buffering (hub node and intermediate node) and PIC Webcache 

15 at end-user node (TR: Socket Matching at HN) 

FIG. 6 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node, with secondary buffering at an intermediate node, and with PIC Webcache 
at an end-user node in a star topology, dual channel network. FIG. 6A illustrates the 
distribution of PIC components in the fifth embodiment. Reference numerals are to FIG. 

20 6 unless otherwise noted. 

A fifth embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (601), an encapsulation 
component (602), and a primary buffering component (619) at the hub node, an initial 
socket matching function in the primary buffering component at the hub node, and a 

25 secondary monitoring component (604), a secondary buffering component (606), and a 
decapsulation component (605) at an intermediate node, and a PIC Webcache (607) at an 
end-user node. In the context of a star topology, dual channel network with a large number 
of remote terminals, the use of a primary buffering component at the hub node permits 
smaller buffer memory and lower performance storage and processor to be used by the 

30 secondary buffering component at the intermediate node. The PIC Webcache is 
configured as a proxy server cache and the Web browser on the end-user computer is 
configured to use such proxy server cache. The primary monitoring component at the hub 
node monitors all inbound channels transmitted from all the remote terminals to the hub 
node. The primary monitoring component (601) copies all HTTP requests from the 

35 monitored inbound channels, and provides each HTTP request to the encapsulation 
component (602) where, as in the fourth embodiment, each HTTP request is encapsulated 
in a UDP packet with a broadcast IP address and port and is then forwarded to the primary 
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buflFeringcomponent(619)atthehubnode. Theprimary buffering component(619) stores 
the encapsulated HTTP request in buffer memory at the hub node, tagged with the source 
socket (source IP address and TCP port number) and the destination socket (destination IP 
address and TCP port number) specified in the HTTP request Upon receipt at the hub 
5 node of an HTTP response, the primary monitoring component (601) provides the HTTP 
response to the primary buffering component (619) at the hub node. The HTTP 
response is not immediately broadcast by the hub node in the outbound channel. The 
primary buffering component (619) at the hub node examines the source and destination 
sockets in the IP packet containing the HTTP response and matches them with the 

1 0 destination and source sockets in the associated, previously UDP-encapsulated IP packet 
containing the HTTP request (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response). After receiving both the HTTP request and 
the HTTP response, the primary buffering component (6 1 9) provides the HTTP request to 
the outbound channel (616) for transmission in the outbound channel using a broadcast IP 

15 address and UDP port (or other suitable protocol, address, and port) monitored by all 
remote terminals that receive such outbound channel and are interfaced with local PIC 
components. The primary buffering component (619), soon after providing the 
encapsulated HTTP request to the outbound channel (616), provides the corresponding 
HTTP response to the outbound channel (616) for transmission to the remote terminals 

20 (609,613). 

The secondary monitoring component (604) at the intermediate node (617 in FIG. 
6A) communicates through a network interface on the intermediate node with the remote 
terminal. The secondary monitoring component (604) also communicates with the 
decapsulation component (605), and with the secondary buffering component (606), at the 

25 intermediate node. The secondary monitoring component (604) copies from the remote 
terminal (603) and forwards through a first portion of a first communications path (610) 
to the decapsulation component (605) on the intermediate node all encapsulated UDP 
packets, and through a second communications path (611) to the secondary buffering 
component on the intermediate node all HTTP packets, received by the remote terminal, 

30 not just those packets with an IP destination address of the intermediate node or of end- 
user nodes served by that remote terminal. When the secondary monitoring component 
(604) on the intermediate node receives a UDP packet containing an encapsulated HTTP 
request, it provides such packet to the decapsulation component through the first portion 
of the first communications path (610). The decapsulation component removes the UDP 

35 encapsulation ("decapsulation"), and forwards through a second portion of the first 
communications path (61 1) each decapsulated HTTP request to the secondary buffering 
component (606) at the intermediate node. The secondary buffering component (606) at 
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the intermediate node communicates with disk drive(s) (612) or other read/write storage 
device(s) associated with each end user node that are used by one or more end-user nodes' 
PIC Webcaches for storage. The secondary buffering component stores the decapsulated 
HTTP request in buffer memory, and opens a file (or database record) tagged with the 

5 source socket (source IP address and TCP port number) and the destination socket 
(destination IP address and TCP port number) specified in the decapsulated HTTP request. 
The tagged file (or database record) would normally be on the storage device(s) used by 
each PIC Webcache interfaced with the intermediate node. The tagged file (or database 
record) awaits the arrival of the contents of the relevant HTTP response from the buffering 

10 component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to each PIC 
Webcache in the normal manner, and delivered by the PIC Webcache associated with an 

15 end-user node, operating as a proxy server cache, to the requesting browser. The 
secondary monitoring component (604) at the intermediate node also forwards through the 
second communications path (61 1) every HTTP response in the outbound channel to the 
secondary buffering component (606) running on the intermediate node. If a browser 
running on an end-user node interfaced with a remote terminal did not originate the HTTP 

20 request that generated the HTTP response, the contents of the HTTP response are not 
passed to the browser upon receipt. Rather, the secondary buffering component on the 
intermediate node examines the HTTP response to determine the source and destination 
sockets and stores the contents of the HTTP response in the file (or database record) 
previously tagged with those sockets (the source and destination sockets are reversed in 

25 the HTTP request as compared with the HTTP response). After receiving both the HTTP 
request and the HTTP response, the secondary buffering component at the intermediate 
node can match the HTTP request with the correct HTTP response, extract the URL 
identity from the HTTP request, and create a file (or database record) for the URL on the 
storage device(s) used by each PIC Webcache as if each PIC Webcache itself had cached 

30 the URL. To receive and store the HTTP response, the PIC system typically uses a local 
area network (61 8) and may use a TCP port number allocated by an end-user node for the 
purpose of directly accessing the disk area of the PIC Webcache on the end-user node. If 
a browser requests that URL in the future, the contents of the URL will already be in the 
PIC Webcache serving the browser, and will be delivered instantly from the PIC Webcache 

35 to the browser. 

Sixth Embodiment : Split Buffering (hub node and intermediate node) and PIC Webcache 
at intermediate node (TR: Socket Matching at HN) 
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FIG. 7 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with PIC Webcache at an intermediate node in a star topology, dual 
channel network. FIG. 7A illustrates the distribution of PIC components in the sixth 
embodiment. Reference numerals are to FIG. 7 unless otherwise noted. 

A sixth embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (701), an encapsulation 
component (702), and a primary buffering component (7 1 9) at a hub node, an initial socket 
matching function in the primary buffering component (719) at the hub node, and a 
secondary monitoring component (704), a secondary buffering component (706), a 
decapsulation component (705), and a PIC Webcache (707) at an intermediate node (717 
in FIG. 7A). In the context of a star topology, dual channel network with a large number 
of remote terminals, the use of a primary buffering component at the hub node permits 
smaller buffer memory and lower performance storage and processor to be used by the 
secondary buffering component at the intermediate node. This embodiment has the 
advantage of requiring only one instance of the secondary monitoring component, 
buffering component, and PIC Webcache to serve all end-user nodes on one or more local 
area networks (or other local connectivity) interfaced with the intermediate node, and 
providing improved response time without the expense of have end-user nodes equipped 
with caching devices. Additionally, high performance memory, storage, and dedicated 
processor can provide performance improvements by off-loading processing and storage 
requirements from the end-user nodes. The end-user nodes may also communicate directly 
with a remote terminal for communications unrelated to the PIC system. The PIC 
Webcache in this embodiment may be configured as a proxy server cache (i.e., browsers 
configured to use a TCP port for HTTP that is uniquely allocated to the PIC Webcache) 
or as a caching appliance (i.e., browsers need not be configured to use a TCP port for 
HTTP that is uniquely allocated to the PIC Webcache, and would normally use well- 
known TCP port 80). The Web browser on the end-user node must be configured for 
proxy server cache if the proxy configuration is implemented. If the PIC Webcache is 
configured as a caching appliance, it is not necessary to configure browsers on end-user 
nodes to use the caching appliance, since using well-known TCP port 80 in the destination 
socket directs HTTP requests through the caching appliance. 

The primary monitoring component (701), the primary buffering component (719), 
and the encapsulation component (702) of the PIC system at the hub node function as 
described above for the fourth and fifth embodiments. In addition, the secondary 
monitoring component (704), the decapsulation component (705), first communications 
path (710), and second communications path (711) at the intermediate node function as 
described above for the fifth embodiment. In the sixth embodiment, the secondary 
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buffering component (706) at the intermediate node communicates with disk drive(s) (712) 
or other read/write storage device(s) located at the intermediate node that are used by one 
or more PIC Webcaches at the intermediate node for storage. The secondary buffering 
component (706) at the intermediate node stores the decapsulated HTTP request in buffer 
5 memory, and opens a file (or database record) tagged with the source socket (source IP 
address and TCP port number) and the destination socket (destination IP address and TCP 
port number) specified in the decapsulated HTTP request. The tagged file (or database 
record) would normally be on the storage device(s) used by a given PIC Webcache at the 
intermediate node. Multiple PIC Webcaches maybe associated with the intermediate node 

10 to enable load-sharing or redundancy. The tagged file awaits the arrival of the contents of 
the relevant HTTP response from the buffering component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote tenninal, forwarded to the relevant PIC 

15 Webcache in the normal manner, and delivered by the PIC Webcache, operating either as 
a proxy server cache or as a cascaded caching appliance, to the requesting browser. The 
secondary monitoring component at the intermediate node forwards every HTTP response 
in the outbound channel to the secondary buffering component running on the intermediate 
node. If a browser running on an end-user node interfaced with a remote terminal did not 

20 originate the HTTP request that generated the HTTP response, the contents of the HTTP 
response are not passed to the browser upon receipt. Rather, the secondary buffering 
component on the intermediate node examines the HTTP response to determine the source 
and destination sockets and stores the contents of the HTTP response in the file (or 
database record) previously tagged with those sockets (the source and destination sockets 

25 are reversed in the HTTP request as compared with the HTTP response). After receiving 
both the HTTP request and the HTTP response, the secondary buffering component at the 
intermediate node can match the HTTP request with the correct HTTP response, extract 
the URL identity from the HTTP request, and create a file (or database record) for the URL 
on the storage device(s) used by one or more PIC Webcaches at the intermediate node as 

30 if the PIC Webcache itself had cached the URL and its contents. To receive and store the 
HTTP response, the PIC system does not obtain or use a TCP port number allocated by 
end-user nodes interfaced with the intermediate node. If a browser on an end-user node 
requests that URL in the future, the contents of the URL will already be in the relevant PIC 
Webcache, and will be delivered from the PIC Webcache to the browser. 

35 Seventh Embodiment : Buffering and PIC Webcache at end-user node (RO: Socket 
Matching at EUN) 

FIG. 8 illustrates the Passive Internet Cache embodiment with socket matching and 
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PIC Webcache at an end-user node in a star topology, single channel network. FIG. 8A 
illustrates the distribution of PIC components in the seventh embodiment. Reference 
numerals are to FIG. 8 unless otherwise noted. 

A seventh embodiment of the PIC system is structurally and functionally identical 
5 the first embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 
10 Eighth Embodiment : Buffering at intermediate node and PIC Webcache at end-user node 
(RO: Socket Matching at IN) 

FIG. 9 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and with PIC Webcache at an end-user node in a star topology, single 
channel network. FIG. 9A illustrates the distribution of PIC components in the eighth 
15 embodiment. Reference numerals are to FIG. 9 unless otherwise noted. 

An eighth embodiment of the PIC system is structurally and functionally identical 
the second embodiment, except the remote terminal is receive only and cannot initiate 
HTTP requests. The inability to initiate HTTP requests, or other return channel messages, 
does not prevent or impair the operation of the components of the PIC system. The PIC 
20 Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 

Ninth Embodiment : Buffering and PIC Webcache at intermediate node (RO: Socket 
Matching at IN) 

FIG. 10 illustrates the Passive Internet Cache embodiment with socket matching 
25 and PIC Webcache at an intermediate node in a star topology, single channel network. 
FIG. 10A illustrates the distribution of PIC components in the ninth embodiment. 
Reference numerals are to FIG. 10 unless otherwise noted. 

A ninth embodiment of the PIC system is structurally and functionally identical the 
third embodiment, except the remote terminal is receive only and cannot initiate HTTP 
30 requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an intermediate node reflects the HTTP requests initiated by other end- 
user nodes that have an inbound channel. 

Tenth Embodiment: Split Buffering (hub and end-user nodes) and PIC Webcache at end- 
35 user node (RO: Socket Matching at HN) 

FIG. 1 1 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache at an end-user node in 
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a star topology, single channel network. FIG. 11A illustrates the distribution of PIC 
components in the tenth embodiment. Reference numerals are to FIG. 1 1 unless otherwise 
noted. 

A tenth embodiment of the PIC system is structurally and functionally identical the 
fourth embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 

Eleventh Embodiment : Split Buffering (hub node and intermediate node) and PIC 
Webcache at end-user node (RO: Socket Matching at HN) 

FIG. 12 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node, with secondary buffering at an intermediate node, and with PIC 
Webcache at an end-user node in a star topology, single channel network. FIG. 12A 
illustrates the distribution of PIC components in the eleventh embodiment. Reference 
numerals are to FIG. 12 unless otherwise noted. 

An eleventh embodiment of the PIC system is structurally and functionally 
identical the fifth embodiment, except the remote terminal is receive only and cannot 
initiate HTTP requests. The inability to initiate HTTP requests, or other return channel 
messages, does not prevent or impair the operation of the components of the PIC system. 
The PIC Webcache built at an end-user node reflects the HTTP requests initiated by other 
end-user nodes that have an inbound channel. 

Twelfth Embodiment: Split Buffering (hub node and intermediate node) and PIC 
Webcache at intermediate node (RO: Socket Matching at HN) 

FIG. 13 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache and at an intermediate 
node in a star topology, single channel network. FIG. 13 A illustrates the distribution of 
PIC components in the twelfth embodiment. Reference; numerals are to FIG. 13 unless 
otherwise noted. 

A twelfth embodiment of the PIC system is structurally and functionally identical 
the sixth embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an intermediate node reflects the HTTP requests initiated by other end- 
user nodes that have an inbound channel. 

For simplicity, in the embodiments that do not allocate TCP ports, if a browser 
running on an end-user node interfaced with a remote terminal originated the HTTP 
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request that generated agiven HTTP response, aPIC system would normally be configured 
so that the same HTTP request after being decapsulated from a UDP message, after receipt 
of the socket-matched HTTP response, causes an overwrite of the URL in the PIC 
Webcache that was already written in response to the HTTP response addressed directly 
to that end-user node's IP address and TCP port number (rather than through the PIC 
system). Such an implementation is said to have "exhaustive writing" of HTTP requests 
received by the PIC buffering component through UDP messages (i.e., does not need to 
recognize local addresses before writing the URL processed through the PIC system). 
Alternatively, a PIC buffering component on an end-user node can be designed for 
"selective writing" so that it does not write any HTTP request received by the PIC 
monitoring component through UDP messages to the PIC Webcache if the destination IP 
address of the HTTP response is that of the node on which the PIC Webcache is running. 
In case of "selective writing", the normal dialog of an HTTP request and an HTTP 
response will cause the requested URL to be written to the browser or cache that originated 
the HTTP request. 

If the necessary decryption keys are available, a PIC system can work with 
encrypted HTTP messages. If encrypted HTTP messages are exchanged, and the necessary 
decryption key is not available to a PIC system, the PIC system is unable to use (or 
possibly detect) HTTP messages that are encrypted. In all embodiments of the PIC system, 
encrypted payloads are simply handled as any other message, i.e. cached in the encrypted 
form if TCP/IP header information is available and HTTP commands are decipherable, or 
discarded if not. Independently of the PIC system components, encrypted HTTP messages 
are processed in a normal manner, so that a browser sending an encrypted HTTP request 
can still receive an encrypted HTTP response. 

The return channel from a hub node through one or more monitoring components, 
encapsulating component, decapsulating component, one or more buffering components, 
to each PIC Webcache can also carry UDP messages that can be used to control HTTP 
content cached by a PIC Webcache based on the URL in an HTTP request or the source 
IP address of an HTTP response. Such access control can be used to permit or prevent 
caching of URLs and their content in a PIC Webcache in order to implement a subscription 
authorization system, or simply to block ccmtent from objectionable network domains, 
hosts, etc. With reference to FIG. 16, implementation of access control using a PIC 
system requires a content authorization program and database associated with or interfaced 
with the hub node (1 620), preparation of content authorization messages addressed to one 
or more buffering components associated with remote terminals by the content 
authorization program, encapsulation of the authorization control messages by the 
encapsulating component (1602) at a hub node, transmission of the encapsulated 
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authorization control messages in the outbound channel (1616), delivery of the 
decapsulated authorization control messages to the each buffering component in the same 
manner as delivery of decapsulated HTTP requests as described above, and execution of 
the authorization control message by an intermediate node content authorization 
5 component (1621) associated with a buffering component (1606) and/or by an end-user 
node content authorization component (1622) associated with a PIC Webcache (1607). 
The authorization control message determines what URLs are cached in a given PIC 
Webcaches; messages exchanged between the buffering component (1606) and a given 
intermediate node or end-user node content authorization component determine what URLs 

10 are blocked from caching. Content authorization components (1621, 1622) associated with 
or interfaced with a remote terminal prevent a PIC Webcache from caching a URL or 
source IP address that is specified as unauthorized ("blocked") for a given PIG Webcache. 
Content authorization through a content authorization program and database is known in 
the art, but its use in conjunction with a PIC system is novel. A content authorization 

1 5 component at different end-user nodes can be used to create end-user PIC Webcaches with 
different content, but associated with a single intermediate node (1617) and intermediate 
node content authorization component (1621). By using a content authorization 
component (1621) at an intermediate node (1617), an additional point of content control 
is introduced. Content authorization at an intermediate node PIC Webcache (not 

20 illustrated) can be implemented in networks that have some end-user nodes equipped with 
PIC Webcaches and some that are not equipped with PIC Webcaches. Different end-user 
nodes can also be assigned to use different PIC Webcaches, and thereby have access to 
different content. 

The buffering component at an intermediate node or at an end-user node can 
25 contain a program that monitors whether the payload of an HTTP request or HTTP 
response has errors based on common error checking methods, such as packet sequence 
number continuity. A given HTTP message may require multiple TCP/IP packets for 
transmission. With reference to FIG. 1 7, TCP inserts a sequence number into each packet 
used to transmit a given HTTP message. For a given HTTP response provided to a PIC 
30 buffering component associated with or interfaced with a remote terminal, only one 
payload of a packet with a given TCP sequence number is needed. If a packet stream for 
a given HTTP request contains more than one packet with the same TCP sequence number 
(upper portion of FIG. 17), the buffering component discards packets with duplicate TCP 
sequence numbers. Such error checking is without the buffering component' s participation 
35 in normal TCP/IP protocol handshakes. By reference to the lower portion of FIG. 17, a 
PIC buffering component associated with or interfaced with a remote terminal can be 
configured to discard HTTP messages determined by the buffering component to have 
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missing TCP sequence numbers. If the remote terminal associated with or interfaced with 
a buffering component has inbound channel capability, and the buffering component 
determines that an HTTP response has a corrupted payload, the buffering component can 
(optionally) use the URL in the decapsulated HTTP request to generate an HTTP request 
from the end-user node (using normal TCP/IP procedures) for the URL at issue, and obtain 
another HTTP response from the relevant Webserver. 

Taking an "end to end" perspective of the handling of UDP messages and HTTP 
responses by PIC components, in PIC embodiments without socket-matching at a hub 
node, for UDP messages, a first end-to-end communications path exists through a 
primary monitoring component and encapsulating component at a hub node, then 
through an outbound channel from the hub node, then through a remote terminal to a 
secondary monitoring component and decapsulating component to a buffering 
component; for HTTP responses, a second end-to-end communications path exists from 
external server computers or traditional caches through the outbound channel of the hub 
node, then through the remote terminal to the secondary monitoring component, and 
then to the buffering component. In PIC embodiments with socket-matching at a hub 
node, for UDP messages, a first end-to-end communications path exists through a 
primary monitoring component, encapsulating component, and primary buffering 
component at a hub node, through the outbound channel from the hub node, then 
through a remote terminal to a secondary monitoring component and decapsulating 
component, then to a secondary buffering component; for HTTP responses, a second 
end-to-end communications path exists from external server computers or traditional 
caches through the primary buffering component at a hub node, then through the 
outbound channel from the hub node, then through a remote terminal to the secondary 
monitoring component and then to the secondary buffering component. 

Those skilled in the art also will readily appreciate that many modifications to the 
invention are possible within the scope of the invention. Another alternative embodiment, 
to provide redundancy, would include more than one PIC buffering component associated 
with a given end-user node. For mixed populations of end-user nodes, an intermediate 
node PIC Webcache can be implemented in networks that have some end-user nodes 
equipped with PIC Webcaches and some that are not equipped with PIC Webcaches. 
Accordingly, the scope of the invention is not intended to be limited to the preferred 
embodiments described above, but only by the appended claims. 



36 



WO 01/88761 



PCT/US01/15575 



CLAIMS 

We claim: 

1 . A system of encapsulation and passive listening, comprising: 

a means hosted on a hub node of a network by which a message from a first network 
5 node to said hub node is encapsulated in a broadcast or multicast message and transmitted 
to one or more other network nodes unable to receive the original transmission of said 
message from said first network node to said hub node, 

a means associated with each of said one or more other network nodes of receiving, 
unencapsulating, and buffering said message when it arrives, and 
10 a means of storing the contents of the decapsulated and buffered message in cache 

memory or storage accessible by an end-user at each of said one or more other network 
nodes. 

2. A system of encapsulation and passive listening, comprising: 

a means hosted on a hub node of a network by which a message from a first network 
1 5 node to said hub node is selected for encapsulation based on one or more criteria, such as 
being an HTTP request or being addressed to a certain network address or socket, then 
encapsulated in a broadcast or multicast message and transmitted to one or more other 
network nodes unable to receive the original transmission of said message from said first 
network node to said hub node, 
20 a means associated with each of said one or more other network nodes of receiving, 

unencapsulating, and buffering said message when it arrives, and 

a means of storing the contents of the decapsulated and buffered message in cache 
memory or storage accessible by an end-user at each of said one or more other network 
nodes. 

25 3. A system of encapsulation and passive listening, according to claim 1 or 2, wherein said 
message transmitted from said hub node to said one or more other network nodes is 
encapsulated in User Datagram Protocol or a transport layer, connectionless protocol 
substantially equivalent to User Datagram Protocol. 
4. A system of socket matching, comprising: 

30 a means hosted on a hub node of a network by which an HTTP request from a first 

network node to said hub node is forwarded to a server computer and by which means a 
copy of said HTTP request is also transmitted to one or more other network nodes unable 
to receive the original transmission of said HTTP request from said first network node to 
said hub node, and by which means a copy of an HTTP response sent by said server 

35 computer in response to said HTTP request is transmitted to said first network node and 
to said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
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nodes, of receiving and buffering said HTTP request when it arrives, and of receiving and 
buffering said HTTP response when it arrives, in buffer memory associated with or 
interfaced with each of said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 

5 nodes, of matching the source socket and destination socket of a buffered HTTP request 
with the source socket and destination socket of a buffered HTTP response (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
response) sent by the server computer in response to said HTTP request and received 
before or after receipt of said HTTP request, and 

10 a means of storing under the URL specified in the matching HTTP request the 

contents of the matched HTTP response in cache memory accessible to an end-user node, 
which end user node is associated with or interfaced with one of said one or more other 
network nodes. 

5. A system of socket matching, comprising: 

15 a means hosted on a hub node of a network by which an HTTP request from a first 

network node to said hub node is forwarded to a server computer and by which means a 
copy of said HTTP request is buffered at said hub node until such time as an HTTP 
response sent by said server computer in response to said HTTP request is received, 
buffered, and matched as described below at said hub node, 

20 a means hosted on said hub node of matching the source socket and destination socket 

of said buffered HTTP request with the source socket and destination socket of said 
buffered HTTP response (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response), 

a means hosted on said hub node of transmitting a matched HTTP response and the 

25 matching HTTP request to one or more other network nodes unable to receive the original 
transmission of said HTTP request from said first network node to said hub node, 

a means, associated with or interfaced with each of said one or more other network 
nodes, of receiving and buffering said HTTP request when it arrives, and of receiving and 
buffering said HTTP response when it arrives, in buffer memory associated with or 

30 interfaced with each of said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
nodes, of matching the source socket and destination socket of a buffered HTTP request 
with the source socket and destination socket of a buffered HTTP response (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 

35 response) sent by the server computer in response to said HTTP request and received 
before or after receipt of said HTTP request, and 

a means of storing under the URL specified in said matching HTTP request the 



38 



WO 01/88761 



PCTVUS01/15575 



contents of said matched HTTP response in cache memory accessible to an end-user node, 
which end user node is associated with or interfaced with one of said one or more other 
network nodes. 

6. A system of socket matching, according to claim 4 or 5, wherein Transmission Control 
' Protocol or a transport layer protocol other than Transmission Control Protocol that uses 

the network addressing and routing capabilities of Internet Protocol, or a protocol other 
than Hypertext Transport Protocol that uses paired network layer addressing and transport 
layer ports in request/response, client/server exchanges substantially equivalent to such use 
in Hypertext Transport Protocol, is used. 

7. A system of socket matching, according to claim 4 or 5, wherein the network is a star 
topology network selected from the group consisting of very small aperture satellite, 
multichannel multipoint distribution service, local multipoint distribution service, 
instructional television fixed service, digital television broadcasting, and digital 
cablecasting. 

8. A system of socket matching, according to claim 4 or 5, wherein each said copy of an 
HTTP request is encapsulated in a broadcast or multicast message before transmission 
from said hub node and is decapsulated upon receipt and prior to buffering at each of said 
one of more other network nodes. 

9. A caching system for a star topology network, comprising: 

a hub node of the star topology network that receives HTTP requests from one or more 
remote terminals, which hub node is interfaced with at least one external server computer 
and transmits UDP datagrams, HTTP requests, and HTTP responses in an outbound 
channel from said hub node of the star topology network, and 

one or more intermediate or end-user nodes of said network that receive said UDP 
datagrams, HTTP requests, and HTTP responses and which one or more intermediate or 
end-user nodes are associated with or interfaced with a means for socket-matching HTTP 
requests and HTTP responses and for storing in an end-user accessible cache the contents 
of a given HTTP response under the URL extracted from a correctly matched HTTP 
request. 

10. A caching system for a star topology network, comprising: 

a hub node of the star topology network that receives HTTP requests from one or more 
remote terminals, which hub node is interfaced with at least one external server computer, 
has a first means for socket-matching, and transmits UDP datagrams, HTTP requests, and 
HTTP responses in an outbound channel from said hub node of the star topology network, 
and 

one or more intermediate or end-user nodes of said network that receive said UDP 
datagrams, HTTP requests, and HTTP responses and which one or more intermediate or 



39 



WO 01/88761 



PCT7US01/15575 



end-user nodes are associated with or interfaced with a second means for socket-matching 
HTTP requests and HTTP responses and for storing in an end-user accessible cache the 
contents of a given HTTP response under the URL extracted from a correctly matched 
HTTP request. 

5 1 1 . A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

10 a secondary monitoring component, a decapsulating component, and a socket- 

matching buffering component associated with one or more intermediate node or end-user 
nodes interfaced with a remote terminal in the star topology network, 

at least one global cache associated with said buffering component and an end-user 
node, or where said buffering component is associated with an intermediate node, said at 
1 5 least one global cache either associated with said buffering component, or associated with 
an end-user node and interfaced with said buffering component, 

communications paths for UDP and HTTP messages from the hub node through 
the outbound channel to each buffering component, 

a means controlled by each associated or interfaced buffering component of writing 
20 files or database records in each associated or interfaced global cache, 

wherein each global cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses with 
said hub node using the star network medium or a different telecommunications medium. 

25 12. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

30 a secondary monitoring component, a decapsulating component, and a socket- 

matching secondary buffering component associated with one or more intermediate nodes 
or end-user nodes interfaced with a remote terminal in the star topology network, 

at least one global cache associated with said secondary buffering component and 
an end-user node, or where said secondary buffering component is associated with an 

35 intermediate node, said at least one global cache is either associated with said secondary 
buffering component, or associated with an end-user node and interfaced with said 
secondary buffering component, 
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communications paths for UDP and HTTP messages from the hub node through 
the outbound channel to each secondary buffering component, 

a means controlled by each associated or interfaced secondary buffering component 
of writing files or database records in each associated or interfaced global cache, 
5 wherein each global cache is accessible by at least one end-user node and contains 

information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
with said hub node using the star network medium or a different telecommunications 
medium. 

10 13. A caching system for a star topology network, according to claim 9, 10, 1 1, or 12, 
wherein Transmission Control Protocol or a transport layer protocol other than 
Transmission Control Protocol that uses network addressing and routing capabilities of 
Internet Protocol is used, or a protocol other than Hypertext Transport Protocol that uses 
paired network layer addressing and transport layer ports in request/response, client/server 

15 exchanges substantially equivalent to such use in Hypertext Transport Protocol is used, or 
a connectionless protocol other than User Datagram Protocol with broadcast or multicast 
addressing substantially equivalent to that of User Datagram Protocol is used. 
14. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 

20 server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

at least one end-user node interfaced with a remote terminal in the star topology 
network, and associated with each such end-user node a secondary monitoring component, 
25 a decapsulating component, a socket-matching buffering component, and at least one 
global cache, 

a first communications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
terminal, the secondary monitoring component and decapsulating component to each said 
30 buffering component, 

a second communications path from said one or more external server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 

a means controlled by each said buffering component of writing files or database 
35 records in said associated global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 
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at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

1 5 . A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
5 server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

at least one intermediate node interfaced with a remote terminal in the star topology 
network, and associated with each such intermediate node a secondary monitoring 
10 component, a decapsulating component, and a socket-matching buffering component, 

at least one global cache associated with an end-user node and interfaced with said 
buffering component, 

a first communications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
15 terminal, the secondary monitoring component and decapsulating component to each said 
buffering component, 

a second communications path from said one or more external server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 
20 ameans controlled by said buffering component of writing files or database records 

in said interfaced global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
25 the star network medium or a different telecommunications medium. 

16. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
30 channel, 

at least one intermediate node interfaced with a remote terminal in the star topology 
network and with at least one end-user node, and associated with each such intermediate 
node is a secondary monitoring component, a decapsulating component, a socket-matching 
buffering component, and at least one global cache, 
35 a first communications path from the hub node through the primary monitoring 

component, encapsulating component, and outbound channel, thence through the remote 
terminal, the secondary monitoring component and decapsulating component to each said 
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buffering component, 

a second communications path from said one or more external server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
5 secondary monitoring component to each said buffering component, 

a means controlled by each said buffering component of writing files or database 
records in said associated global cache, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
10 and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

17. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
15 server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

at least one end-user node interfaced with a remote terminal in the star topology 
network, and associated with each such end-user node a secondaiy monitoring component, 
20 a decapsulating component, a socket-matching secondary buffering component, and at least 
one global cache, 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
channel, thence through the remote terminal, said secondary monitoring component and 
25 decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 
30 a means controlled by each secondaiy buffering component of writing files or 

database records in said associated global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
35 the star network medium or a different telecommunications medium. 

1 8. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
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server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

at least one intermediate node interfaced with a remote terminal in the star topology 
network and interfaced with at least one end-user node, and associated with each such 
intermediate node a secondary monitoring component, a decapsulating component, and a 
socket-matching secondary buffering component, 

at least one global cache associated with each said end-user node and interfaced 
with said secondary buffering component, 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
channel, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each secondary buffering component of writing files or 
database records in said interfaced global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
19. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

at least one intermediate node interfaced with a remote terminal in the star topology 
network, and associated with each such intermediate node a secondary monitoring 
component, a decapsulating component, a socket-matching secondary buffering 
component, and at least one global cache, 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
channel, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
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through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each said secondary buffering component of writing files or 
5 database records in said associated global cache, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node using 
10 the star network medium or a different telecommunications medium. 

20. Acachingsystemforastartopologynetwork,accordingtoclaim9, 10, 11, 12, 14, 15, 
16, 17, 18, or 19, wherein the star networking technology is very small aperture satellite 
("VSAT"), multichannel multipoint distribution service ("MMDS"), local multipoint 
distribution service ("LMDS"), instructional television fixed service ("ITFS"), digital 

1 5 television broadcasting, or digital cablecasting. 

21. A caching system for a star topology network, according to claim 9, 10, 11, 12, 14, 15, 
1 6, 1 7, 1 8, or 1 9, wherein a Passive Internet Cache system concurrently uses one or more 
wireline outbound channels, wireless outbound channels, wireline inbound channels, 
and/or wireless inbound channels. 

20 22. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein the network layer protocol is Internet Protocol or a protocol that uses 
network addressing and routing substantially equivalent to that of Internet Protocol is used, 
the transport layer protocol used in the first communications path to encapsulate an HTTP 
request is User Datagram Protocol or a connectionless protocol substantially equivalent to 

25 that of User Datagram Protocol is used, the transport layer protocol used in the second 
communications path is Transport Control Protocol or a connection-oriented protocol 
substantially equivalent to Transport Control Protocol is used, or the applications and 
services protocol is a protocol other than Hypertext Transport Protocol that uses paired 
network layer addressing and transport layer ports in request/response, client/server 

30 exchanges substantially equivalent to that of Hypertext Transport Protocol. 

23. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein caching through the second communications path to one or more global 
caches of specified URLs, or payloads of HTTP messages with specified IP addresses, is 
blocked or authorized by a content authorization program implemented through the first 

35 communications path. 

24. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein the HTTP responses received through the second communications path are 

45 



WO 01/88761 



PC17US01/15575 



examined by said buffering component associated with an intermediate node or an end-user 
node, and if said buffering component detects one or more errors in the payload of an 
HTTP response, said buffering component discards each HTTP response containing such 
error(s) and the corresponding buffered HTTP request. 
5 25. A caching system for a star topology network, according to claim 14, 15, 16, 17, 1 8, 
or 19, wherein there is a means by which HTTP responses received through the second 
communications path are examined by said buffering component associated with an 
intermediate node or an end-user node, and if said buffering component detects an error 
in the payload of an HTTP response and said buffering component is associated with or 
10 interfaced with an inbound channel, the buffering component extracts the relevant URL 
from the corresponding decapsulated and buffered HTTP request, prepares an HTTP 
request for such URL, and causes the transmission of the prepared HTTP request in such 
inbound channel. 

* 26. A caching system for a star topology network, according to claim 14, 15, or 16, further 
15 comprising: 

a means by which each HTTP request inbound from a remote terminal is relayed to 
a server computer and a copy of said HTTP request is encapsulated in a UDP datagram at 
a hub node and distributed through the first communications path to all secondary 
monitoring components associated with or interfaced with an intermediate node or an end- 

20 user node in the star topology network, each of which secondary monitoring component 
forwards such encapsulated HTTP request to a decapsulating component associated with 
such secondary monitoring component, such decapsulating component decapsulates such 
HTTP request and forwards such decapsulated HTTP request to a buffering component 
associated with such decapsulating component, and such decapsulated HTTP request is 

25 tagged by the buffering component based on source socket and destination socket and 
buffered; and 

one or more remote terminals, each of which remote terminals is associated with or 
interfaced with an intermediate node or end-user node and has a means to output each 
HTTP response received through the second communications path to a secondary 

30 monitoring component associated with or interfaced with such intermediate node or end- 
user node, wherein such secondary monitoring component forwards such HTTP response 
to a buffering component associated with such secondary monitoring component, such 
buffering component examines the source socket and destination socket of such HTTP 
response and the source socket and destination socket of each HTTP request that has been 

35 buffered and either (a) if the buffering component matches such HTTP response with a 
buffered HTTP request that contains the corresponding source socket and destination 
socket (the source and destination sockets are reversed in the HTTP request as compared 
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with the HTTP response), then the buffering component stores in a global cache associated 
with or interfaced with the buffering component and accessible by one or more end-users 
the contents of the HTTP response under the URL contained in the HTTP request, or (b) 
if the buffering component can not match such HTTP response with a buffered HTTP 
5 request that contains a corresponding source socket and destination socket, such HTTP 
response is tagged by the buffering component based on source socket and destination 
socket of said HTTP response and buffered, then periodically thereafter the buffering 
component attempts to match the source socket and destination socket of such buffered 
HTTP response with subsequently buffered HTTP requests and upon successfully 

10 matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), then the buffering component stores in a global cache associated with or 
interfaced with the buffering component and accessible by one or more end-users the 
contents of the HTTP response under the URL extracted from in the HTTP request, and 

15 if the sockets of an HTTP response cannot be matched before the expiration of an operator- 
defined time, the buffering component discards such HTTP response; if the sockets of an 
HTTP request cannot be matched before the expiration of an operator-defined time, the 
buffering component discards such HTTP request unless the buffering component has 
access to a forward communications channel and in which case issues an HTTP request 

20 containing the URL in the unmatched and buffered HTTP request 

27. A caching system for a star topology network, according to claim 1 7, 1 8, or 19, further 
comprising: 

a means by which each HTTP request inbound from a remote terminal is relayed to 
a server computer and a copy of such HTTP request is encapsulated in a UDP datagram 

25 at said hub node and buffered in a primary buffering component pending the arrival at the 
hub node of a corresponding HTTP response, and upon arrival of such corresponding 
HTTP response, said HTTP response is buffered in said primary buffering component and 
said primary buffering component examines the source socket and destination socket of 
such HTTP response and the source socket and destination socket of each HTTP request 

30 that has been encapsulated and buffered and either (a) if the primary buffering component 
matches such buffered HTTP response with an encapsulated and buffered HTTP request 
that contains the corresponding source socket and destination socket (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
response), then the primary buffering component forwards the encapsulated and matched 

35 HTTP request through the first communications path to all secondary monitoring 
components associated with or interfaced with an intermediate node or an end-user node 
in the star topology network, each of which secondary monitoring component forwards 
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such encapsulated HTTP request to a decapsulating component associated with such 
secondary monitoring component, such decapsulating component decapsulates such HTTP 
request and forwards such decapsulated HTTP request to a secondary buffering component 
associated with such decapsulating component, and such decapsulated HTTP request is 
5 tagged by the secondary buffering component based on source socket and destination 
socket and buffered, or (b) if the primary buffering component can not match an 
encapsulated buffered HTTP request with a buffered HTTP response that contains a 
corresponding source socket and destination socket, the primary buffering component 
either issues another HTTP request, without encapsulation, addressed to the relevant server 

10 computer and receives a corresponding HTTP response that the secondary buffering 
component successfully socket-matches, or discards such encapsulated and buffered HTTP 
request, as determined by operator-defined configuration settings, and only after 
forwarding of an encapsulated HTTP request through the first communications path under 
(a) above, the primary buffering component at the hub node forwards the matching HTTP 

15 response through the second communications channel, and 

a means associated with or interfaced with each intermediate node or end-user node 
that outputs each HTTP response received through the second communications path to a 
• secondary monitoring component associated with or interfaced with such intermediate 
node or end-user node, wherein such secondary monitoring component forwards such 

20 HTTP response to a secondary buffering component associated with such secondary 
monitoring component, such secondary buffering component examines the source socket 
and destination socket of such HTTP response and the source socket and destination socket 
of each HTTP request that has been buffered and either (a) if the secondary buffering 
component matches such HTTP response with a buffered HTTP request that contains the 

25 corresponding source socket and destination socket (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response), then the secondary 
buffering component stores in a global cache associated with or interfaced with the 
secondary buffering component and accessible by one or more end-users the contents of 
the HTTP response under the URL contained in the HTTP request, or (b) if the secondary 

30 buffering component can not match such HTTP response with a buffered HTTP request 
that contains a corresponding source socket and destination socket, such HTTP response 
is tagged by the secondary buffering component based on source socket and destination 
socket of said HTTP response and buffered, then periodically thereafter the secondary 
buffering component attempts to match the source socket and destination socket of such 

35 buffered HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
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HTTP response), then the secondary buffering component stores in a global cache 
associated with or interfaced with the secondary buffering component and accessible by 
one or more end-users the contents of the HTTP response under the URL extracted from 
in the HTTP request, and if the sockets of an HTTP response cannot be matched before the 
5 expiration of an operator-defined time, the secondary buffering component discards such 
HTTP response; if the sockets of an HTTP request cannot be matched before the expiration 
of an operator-defined time, the secondary buffering component discards such HTTP 
request unless the secondary buffering component has access to a forward communications 
channel and in which case issues an HTTP request containing the URL in the unmatched 
10 and buffered HTTP request. 

28. A method of encapsulation and passive listening, comprising: 

receiving and buffering on a hub node of a network a message from a first network 
node to said hub node, encapsulating said message within a broadcast or multicast 
message, and transmitting said broadcast or multicast message to one or more other 

15 network nodes unable to receive the original message transmission from said first network 
node to said hub node, 

receiving said broadcast or multicast message, and unencapsulating and buffering said 
original message from said first node, when said broadcast or multicast message arrives 
at each of said one or more other network nodes, and 

20 storing the contents of the decapsulated and buffered message in cache memory or 

storage accessible by an end-user at each of said one or more other network nodes. 

29. A method of encapsulation and passive listening, comprising: 

receiving and buffering on a hub node of a network a message from a first network 
node to said hub node, selecting said message for encapsulation based on one or more 
25 criteria, such as being an HTTP request or being addressed to a certain network address or 
socket, encapsulating said message within a broadcast or multicast message, and 
transmitting said broadcast or multicast message to one or more other network nodes 
unable to receive the original message transmission from said first network node to said 
hub node, 

30 when said broadcast or multicast message arrives at each of said one or more other 

network nodes, receiving said broadcast or multicast message, and unencapsulating and 
buffering said original message from said first node, at each of said one or more other 
network nodes, and 

storing the contents of the decapsulated and buffered message in cache memory or 
35 storage accessible by an end-user at each of said one or more other network nodes. 

30. A method of encapsulation and passive listening, according to claim 28 or 29, wherein 
said message transmitted from said hub node to said one or more other network nodes is 
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encapsulated in User Datagram Protocol or a transport layer, connectionless protocol 
substantially equivalent to User Datagram Protocol. 

31. A method of socket matching, comprising: 

receiving and buffering on a hub node of a network an HTTP request from a first 
5 network node to said hub node, forwarding said HTTP request to a server computer and 
also copying said HTTP request and transmitting said HTTP request to one or more other 
network nodes unable to receive the original transmission of said HTTP request from said 
first network node to said hub node, receiving an HTTP response sent by said server 
computer in response to said HTTP request, and transmitting said HTTP response to said 
10 first network node and to said one or more other network nodes, 

at each of said one or more other network nodes, receiving and buffering said HTTP 
request when it arrives, and receiving and buffering said HTTP response when it arrives, 
in buffer memory associated with or interfaced with each of said one or more other 
network nodes, 

1 5 in said buffer memory at each of said one or more other network nodes, matching the 

source socket and destination socket of a buffered HTTP request with the source socket 
and destination socket of a buffered HTTP response (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response) sent by the server 
computer in response to said HTTP request and received before or after receipt of said 

20 HTTP request, and 

storing under the URL specified in the matching HTTP request the contents of the 
matched HTTP response in cache memory accessible to an end-user node, which end user 
node is associated with or interfaced with one of said one or more other network nodes. 

32. A method of socket matching, comprising: 

25 receiving and buffering on a hub node of a network an HTTP request from a first 

network node to said hub node, forwarding said HTTP request to a server computer and 
also copying said HTTP request and buffering in buffer memory said copied HTTP 
request until such time as an HTTP response sent by said server computer in response to 
said HTTP request is received, buffered, and matched as described below at said hub node 

30 receiving and buffering at said hub node an HTTP response sent by said server 

computer in response to said HTTP request 

in said buffer memory said hub node, matching the source socket and destination 
socket of a buffered HTTP request with the source socket and destination socket of a 
buffered HTTP response (the source and destination sockets are reversed in the HTTP 

35 request as compared with the HTTP response) sent by the server computer in response to 
said HTTP request and received before or after receipt of said HTTP request, and 

transmitting said matched HTTP request from said hub node to one or more other 
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network nodes unable to receive the original transmission of said HTTP request from said 
first network node to said hub node, and transmitting said matching HTTP response to said 
first network node and to said one or more other network nodes, 

at each of said one or more other network nodes, receiving and buffering said HTTP 
request when it arrives, and receiving and buffering said HTTP response when it arrives, 
in buffer memory associated with or interfaced with each of said one or more other 
network nodes, 

in said buffer memory at each of said one or more other network nodes, matching the 
source socket and destination socket of a buffered HTTP request with the source socket 
and destination socket of a buffered HTTP response (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response) sent by the server 
computer in response to said HTTP request and received before or after receipt of said 
HTTP request, and 

storing under the URL specified in the matching HTTP request the contents of the 
matched HTTP response in cache memory accessible to an end-user node, which end user 
node is associated with or interfaced with one of said one or more other network nodes. 

33. A method of socket matching, according to claim 3 1 or 32, wherein Transmission 
Control Protocol or a transport layer protocol other than Transmission Control Protocol 
that uses network addressing and routing capabilities of Internet Protocol, or a protocol 
other than Hypertext Transport Protocol that uses paired network layer addressing and 
transport layer ports in request/response, client/server exchanges substantially equivalent 
to that of Hypertext Transport Protocol, is used. 

34. A method of socket matching, according to claim 3 1 or 32, wherein the network is a 
star topology network selected from the group consisting of very small aperture satellite, 
multichannel multipoint distribution service, local multipoint distribution service, 
instructional television fixed service, digital television broadcasting, and digital 
cablecasting. 

35. A method of socket matching, according to claim 3 1 or 32, wherein each said copy of 
an HTTP request is encapsulated in a broadcast or multicast message before transmission 
from said hub node and is decapsulated upon receipt and prior to buffering at each of said 
one of more other network nodes. 

36. A caching method for a star topology network, comprising: 

receiving HTTP requests from one or more remote terminals at a hub node of the star 
topology network, interfacing said hub node with at least one external server computer, and 
transmitting UDP datagrams, HTTP requests, and HTTP responses in an outbound channel 
from said hub node of the star topology network, and 
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receiving said UDP datagrams, HTTP requests, and HTTP responses at one or more 
intermediate or end-user nodes associated with or interfaced with a remote terminal of said 
star topology network, socket-matching said HTTP requests and HTTP responses at said 
one or more intermediate or end-user nodes, and storing in an end-user accessible cache 
5 associated with or interfaced with said one or more intermediate or end-user nodes the 
contents of a given HTTP response under the URL extracted from a correctly matched 
HTTP request 

37. A caching method for a star topology network, comprising: 

receiving HTTP requests from one or more remote terminals at a hub node of the star 
10 topology network, interfacing said hub node with at least one external server computer, 
socket-matching HTTP requests and HTTP responses at said hub node, and transmitting 
UDP datagrams, HTTP requests, and HTTP responses in an outbound channel from said 
hub node of the star topology network to said one or more remote terminals, and 

receiving said UDP datagrams, HTTP requests, and HTTP responses at one or more 
1 5 intermediate or end-user nodes associated with or interfaced with a remote terminal of said 
star topology network, socket-matching said HTTP requests and HTTP responses at said 
one or more intermediate or end-user nodes, and storing in an end-user accessible cache 
at said one or more intermediate or end-user nodes the contents of a given HTTP response 
under the URL extracted from a correctly matched HTTP request 
20 38. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, and an outbound channel, 
associating with at least one intermediate node or end-user node interfaced with a 
25 remote terminal in the star topology network a secondary monitoring component, a 
decapsulating component, and a socket-matching buffering component, 

associating with said buffering component and an end-user node at least one global 
cache, or where said buffering component is associated with an intermediate node, 
associating with or interfacing with said buffering component and an intermediate node at 
30 least one global cache, 

providing communications paths for UDP and HTTP messages from the hub node 
through the outbound channel to each buffering component, 

controlling the writing of files or database records in said global cache by means 
of said associated or interfaced buffering component, 
35 wherein each global cache is accessible by at least one end-user node and contains 

information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
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with said hub node using the star network medium or a different telecommunications 
medium. 

39. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
5 server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, a socket-matching primary 
buffering component, and an outbound channel, 

associating with at least one intermediate node or end-user node interfaced with a 
remote terminal in the star topology network a secondary monitoring component, a 
10 decapsulating component, and a socket-matching secondary buffering component, 

associating with said secondary buffering component and an end-user node at least 
one global cache, or where said secondary buffering component is associated with an 
intermediate node, associating with or interfacing with said secondary buffering 
component and an intermediate node at least one global cache, 
15 providing communications paths for UDP and HTTP messages from the hub node 

through the outbound channel to each secondary buffering component, 

controlling the writing of files or database records in said global cache by means 
of said associated or interfaced secondary buffering component, 

wherein each global cache is accessible by at least one end-user node and contains 
20 information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
with said hub node using the star network medium or a different telecommunications 
medium. 

40. A caching method for a star topology network, according to claim 36, 37, 38, or 39, 
25 wherein Transmission Control Protocol or a transport layer protocol other than 

Transmission Control Protocol that uses the network addressing and routing capabilities 
of Internet Protocol is used, or aprotocol other than Hypertext Transport Protocol that uses 
paired network layer addressing and transport layer ports in request/response, client/server 
exchanges substantially equivalent to such use in Hypertext Transport Protocol is used, or 
30 a connectionless protocol other than User Datagram Protocol with broadcast or multicast 
addressing substantially equivalent to that of User Datagram Protocol, is used. 

41. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
35 a primary monitoring component, an encapsulating component, and an outbound channel, 

associating with at least one end-user node interfaced with a remote terminal in the 
star topology network a secondary monitoring component, a decapsulating component, a 
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socket-matching buffering component, and at least one global cache, 

providing a first communications path from the hub node through the primary 
monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
5 to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said associated global cache 
10 by means of said buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
15 42. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external server 
computers, and internal to the star topology network associating with the hub node a 
primary monitoring component, an encapsulating component, and an outbound channel, 
associating with at least one intermediate node interfaced with a remote terminal in 
20 the star topology network a secondary monitoring component, a decapsulating component, 
and a socket-matching buffering component, 

associating at least one global cache with at least one end-user node interfaced with 
said buffering component, 

providing a first communications path from the hub node through the primary 
25 monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
30 terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said interfaced global cache by 
means of said buffering component, 

wherein said global cache is accessible by said end-user node and contains information 
or data from said server computers, and 
35 at least one end-user node is able to exchange messages with said hub node using the 

star network medium or a different telecommunications medium. 
43. A caching method for a star topology network, comprising: 
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interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, and an outbound channel, 

associating with at least one intermediate node interfaced with a remote terminal 
5 in the star topology network a secondary monitoring component, a decapsulating 
component, a socket-matching buffering component, and at least one global cache, 

providing a first communications path from the hub node through the primary 
monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
10 to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said associated global cache 
15 by means of said buffering component, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node using 
20 the star network medium or a different telecommunications medium. 
44. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, a socket-matching primary 
25 buffering component, and an outbound channel, 

associating with at least one end-user node interfaced with a remote terminal in the 
star topology network a secondary monitoring component, a decapsulating component, a 
socket-matching secondary buffering component, and at least one global cache, 

providing a first communications path from the hub node through said primary 
30 monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
component and decapsulating component to each said secondary buffering component, 

providing a second communications path from said one or more external server 
computers through the primary monitoring component, primary buffering component, and 
35 outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said associated global cache 
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by means of said secondary buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

45. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
aprimary monitoring component, an encapsulating component, a socket-matching primary 
buffering component, and an outbound channel, 

associating with at least one intermediate node interfaced with a remote terminal 
in the star topology network a secondary monitoring component, a decapsulating 
component, and a socket-matching secondary buffering component, 

associating at least one global cache with at least one end-user node interfaced with 
said secondary buffering component, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
component and decapsulating component to each said secondary buffering component, 

providing a second communications path from said one or more external server 
computers through the primary monitoring component, primary buffering component, and 
outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said interfaced global cache 
by means of said secondary buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

46, A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
aprimary monitoring component, an encapsulating component, a socket-matching primary 
buffering component, and an outbound channel, 

associating with at least one intermediate node interfaced with a remote terminal 
in the star topology network a secondary monitoring component, a decapsulating 
component, a socket-matching secondary buffering component, and at least one global 
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cache, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
component and decapsulating component to each said secondary buffering component, 

providing a second communications path from said one or more external server 
computers through the primary monitoring component, primary buffering component, and 
outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said associated global cache 
by means of said secondary buffering component, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

47. A caching method for a star topology network, according to claim 36, 37, 38, 40, 41, 
42, 43, 44, 45, or 46, wherein the star networking technology is very small aperture 
satellite ("VSAT"), multichannel multipoint distribution service ("MMDS"), local 
multipoint distribution service ("LMDS"), instructional television fixed service ("ITFS"), 
digital television broadcasting, or digital cablecasting. 

48. A caching method for a star topology network, according to claim 36, 37, 38, 40, 41, 
42, 43, 44, 45, or 46, wherein a Passive Internet Cache system concurrently uses one or 
more wireline outbound channels, wireless outbound channels, wireline inbound channels, 
and/or wireless inbound channels. 

49. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein the network layer protocol is Internet Protocol or a protocol that uses 
network addressing and routing substantially equivalent to that of Internet Protocol is used, 
the transport layer protocol used in the first communications path to encapsulate an HTTP 
request is User Datagram Protocol or a connectionless protocol substantially equivalent to 
that of User Datagram Protocol is used, the transport layer protocol used in the second 
communications path is Transport Control Protocol or a connection-oriented protocol 
substantially equivalent to Transport Control Protocol is used, or the applications and 
services protocol is a protocol other than Hypertext Transport Protocol that uses paired 
network layer addressing and transport layer ports in request/response, client/server 
exchanges substantially equivalent to that of Hypertext Transport Protocol. 

50. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
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or 46, wherein caching through the second communications path to one or more global 
caches of specified URLs, or payloads of HTTP messages with specified IP addresses, is 
blocked or authorized by a content authorization program implemented through the first 
communications path. 

5 1 . A caching method for a star topology network, according to claim 41 , 42, 43, 44, 45, 
or 46, wherein the HTTP responses received through the second communications path are 
examined by said buffering component associated with an intermediate node or an end-user 
node, and if said buffering component detects one or more errors in the payload of an 
HTTP response, said buffering component discards each HTTP response containing such 
error(s) and the corresponding buffered HTTP request. 

52. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein there is a means by which HTTP responses received through the second 
communications path are examined by said buffering component associated with an 
intermediate node or an end-user node, and if said buffering component detects an error 
in the payload of an HTTP response and said buffering component is associated with or 
interfaced with an inbound channel, the buffering component extracts the relevant URL 
from the corresponding decapsulated and buffered HTTP request, prepares an HTTP 
request for such URL, and causes the transmission of the prepared HTTP request in such 
inbound channel. 

53. A caching method for a star topology network, according to claim 41, 42, or 43, 
further comprising: 

relaying each HTTP request inbound from a remote terminal through the hub node to 
a server computer and encapsulating a copy of each said HTTP request in a UDP datagram 
at said hub node, distributing said UDP datagram through the first communications path 
to all secondary monitoring components associated with or interfaced with an intermediate 
node or an end-user node in the star topology network, forwarding such encapsulated 
HTTP request from each such secondary monitoring component to a decapsulating 
component associated with each such secondary monitoring component, decapsulating 
such HTTP request in the decapsulating component, forwarding such decapsulated HTTP 
request from such decapsulating component to a buffering component associated with such 
decapsulating component, and tagging by such buffering component of each such 
decapsulated HTTP request based on source socket and destination socket and buffered; 
and 

associating with or interfacing with one or more remote terminals an intermediate 
node or end-user node, outputting from each such remote terminal each HTTP response 
received through the second communications path to a secondary monitoring component 
associated with or interfaced with such intermediate node or end-user node, forwarding 



58 



WO 01/88761 



PCT/US01/15575 



from the secondary monitoring component such HTTP response to a buffering component 
associated with such secondary monitoring component, examining the source socket and 
destination socket of such HTTP response and the source socket and destination socket of 
each HTTP request that has been buffered by such buffering component, and either (a) if 
5 the buffering component matches such HTTP response with a buffered HTTP request that 
contains the corresponding source socket and destination socket (the source and destination 
sockets are reversed in the HTTP request as compared with the HTTP response), then 
storing by the buffering component in a global cache associated with or interfaced with the 
secondary buffering component and accessible by one or more end-users the contents of 

10 the HTTP response under the URL contained in the HTTP request, or (b) if the buffering 
component can not match such HTTP response with a buffered HTTP request that contains 
a corresponding source socket and destination socket, tagging such HTTP response by the 
buffering component based on source socket and destination socket of said HTTP response 
and buffering such tagged HTTP response, then periodically thereafter attempting by the 

15 buffering component to match the source socket and destination socket of such buffered 
HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), storing by the buffering component in a global cache associated with or 

20 interfaced with the secondary buffering component and accessible by one or more end- 
users the contents of the HTTP response under the URL extracted from in the HTTP 
request, and if the sockets of an HTTP response cannot be matched before the expiration 
of an operator-defined time, discarding by the buffering component of such HTTP 
response; if the sockets of an HTTP request cannot be matched before the expiration of an 

25 operator-defined time, discarding by the buffering component of such HTTP request unless 
the buffering component has access to a forward communications channel and in which 
case issuing by the buffering component of an HTTP request containing the URL in the 
unmatched and buffered HTTP request. 

54. A caching method for a star topology network, according to claim 44, 45, or 46, 

30 further comprising: 

relaying each HTTP request inbound from a remote terminal through the hub node to 
a server computer and encapsulating a copy of each said HTTP request in a UDP datagram 
at said hub node, buffering said UDP datagram in a primary buffering component pending 
the arrival at the hub node of a corresponding HTTP response, and upon arrival of such 

35 corresponding HTTP response, buffering said HTTP response in said primary buffering 
component, examining by said primary buffering component of the source socket and 
destination socket of such HTTP response and the source socket and destination socket of 
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each HTTP request that has been encapsulated and buffered and either (a) if the primary 
buffering component matches such buffered HTTP response with an encapsulated and 
buffered HTTP request that contains the corresponding source socket and destination 
socket (the source and destination sockets are reversed in the HTTP request as compared 
with the HTTP response), forwarding by the primary buffering component of the 
encapsulated and matched HTTP request through the first communications path to all 
secondary monitoring components associated with or interfaced with an intermediate node 
or an end-user node in the star topology network, forwarding by each such secondary 
monitoring components of such encapsulated HTTP request to a decapsulating component 
associated with such secondary monitoring component, decapsulating by the decapsulating 
component of such HTTP request, forwarding such decapsulated HTTP request to a 
secondary buffering component associated with such decapsulating component, and 
tagging of such decapsulated HTTP request by the secondary buffering component based 
on source socket and destination socket and buffered, or (b) if the primary buffering 
component cannot match an encapsulated buffered HTTP request with a buffered HTTP 
response that contains a corresponding source socket and destination socket, either issuing 
by the primary buffering component of another HTTP request, without encapsulation, 
addressed to the relevant server computer and receiving a corresponding HTTP response 
that the secondary buffering component successfully socket-matches, or discarding such 
encapsulated and buffered HTTP request, as determined by operator-defined configuration 
settings, and only after forwarding of an encapsulated HTTP request through the first 
communications path under (a) above, forwarding by the primary buffering component at 
the hub node of the matching HTTP response through the second communications channel, 
and 

associating with or interfacing with one or more remote terminals an intermediate 
node or end-user node, outputting from each such remote terminal each HTTP response 
received through the second communications path to a secondary monitoring component 
associated with or interfaced with such intermediate node or end-user node, forwarding 
from the secondary monitoring component such HTTP response to a secondary buffering 
component associated with such secondary monitoring component, examining the source 
socket and destination socket of such HTTP response and the source socket and destination 
socket of each HTTP request that has been buffered by such secondary buffering 
component, and either (a) if the secondary buffering component matches such HTTP 
response with a buffered HTTP request that contains the corresponding source socket and 
destination socket (the source and destination sockets are reversed in the HTTP request as 
compared with the HTTP response), then storing by the secondary buffering component 
in a global cache associated with or interfaced with the secondary buffering component and 
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accessible by one or more end-users the contents of the HTTP response under the URL 
contained in the HTTP request, or (b) if the secondary buffering component can not match 
such HTTP response with a buffered HTTP request that contains a corresponding source 
socket and destination socket, tagging such HTTP response by the secondary buffering 
component based on source socket and destination socket of said HTTP response and 
buffering such tagged HTTP response, then periodically thereafter attempting by the 
secondary buffering component to match the source socket and destination socket of such 
bufferedHTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), storing by the secondary buffering component in a global cache 
associated with or interfaced with the secondary buffering component and accessible by 
one or more end-users the contents of the HTTP response under the URL extracted from 
in the HTTP request, and if the sockets of an HTTP response cannot be matched before the 
expiration of an operator-defined time, discarding by the secondary buffering component 
of such HTTP response; if the sockets of an HTTP request cannot be matched before the 
expiration of an operator-defined time, discarding by the secondary buffering component 
of such HTTP request unless the secondary buffering component has access to a forward 
communications channel and in which case issuing by the secondary buffering component 
of an HTTP request containing the URL in the unmatched and buffered HTTP request. 
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